W3C home > Mailing lists > Public > www-svg@w3.org > August 2004

Re: WG clarification request for SVG_WRONG_TYPE_ERR

From: Dean Jackson <dean@w3.org>
Date: Fri, 6 Aug 2004 23:36:43 +1000
To: Jonathan Watt <jonathan.watt@strath.ac.uk>
Cc: www-svg@w3.org
Message-ID: <20040806133643.GX13917@grorg.local>

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

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:14:53 UTC