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

Re: WG clarification request for SVG_WRONG_TYPE_ERR

From: Jonathan Watt <jonathan.watt@strath.ac.uk>
Date: Sat, 7 Aug 2004 18:17:04 +0100 (BST)
To: www-svg@w3.org
Message-ID: <Pine.GSO.4.10.10408071814260.19383-100000@shetland>

Hi Dean,

Thanks for replying. Let's see if I can reply to the list instead of just
you this time. :-)

On Fri, 6 Aug 2004, Dean Jackson wrote:

> 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.

I would like to throw SVG_WRONG_TYPE_ERR. Having said that, as Boris
pointed out to me previously, it doesn't seem to make sense to say that
you can only pass in an object of type A, but also to say an error should
be thrown if what was passed in wasn't of type A. In a strongly typed
language, that situation can't arise. In a weakly typed language, the
distinction doesn't exist. If we follow this logic there's no reason for
SVG_WRONG_TYPE_ERR to exist, but I'm not quite sure what's meant by "type"
in ECMAScript. Also the spec doesn't define exactly what is meant by "is
the wrong type of object". Nevertheless, although I'm still thinking about
this, my current opinion is that since ECMAScript objects can morph as
pointed out, implementations will require objects passed into many methods
to be their own implementations of the SVG interfaces concerned. Perhaps
SVG_WRONG_TYPE_ERR should then be thrown if objects are not the UA's

> > 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

I'd want to raise SVG_WRONG_TYPE_ERR also.

Received on Saturday, 7 August 2004 17:17:08 UTC

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