Re: WG clarification request for SVG_WRONG_TYPE_ERR

On Thu 05 Aug 2004, Jonathan Watt wrote:

> I'm looking for WG clarification on why SVG_WRONG_TYPE_ERR isn't
> required to be thrown by all DOM methods that require arguments
> to provide an SVG interface when there is no sensible action to take if
> the argument doesn't support the interface. I specifically want to know
> what should happen when createSVGTransformFromMatrix is passed an object
> that is not an SVGMatrix. Should SVG_WRONG_TYPE_ERR be thrown? Should an
> implementation defined exception be thrown - in which case why not an
> SVG_WRONG_TYPE_ERR? Or should the identity matrix be used and no error
> reported? Or is there some other course of action that makes sense?

I'm not the expert on this but it seems to me as if
the SVG_WRONG_TYPE_ERR should be thrown in these
cases. I don't like the idea of default values if you
pass in dodgy objects.

What do you think?

If you agree, I'll propose this as an errata.

> In the case of createSVGTransformFromMatrix there is the possibility of
> using the identity matrix, although it would seem bad not to notify the
> user of the error to help them debug, but for some methods there is no
> real course of action. For example, in SVGSVGElement, what should happen
> for getIntersectionList or getEnclosureList if rect is not an SVGRect or
> if referenceElement isn't an SVGElement or null?

Hmmm... in the DOM subset implement for JSR 226, we throw
NOT_SUPPORTED_ERROR when you pass null into a getter,
and INVALID_ACCESS_ERR when used in a setter (this is
for trait access, and in an API where we want to keep
the total number of classes to a minimum).

I'll ask you, what do you think "null" should do? 
I'd suggest SVG_WRONG_TYPE again.

Dean

Received on Friday, 6 August 2004 09:37:16 UTC