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: Wed, 11 Aug 2004 16:41:29 +0100 (BST)
To: www-svg@w3.org
Message-ID: <Pine.GSO.4.10.10408111639360.11035-100000@shetland>

On Sat, 7 Aug 2004, Boris Zbarsky wrote:

> 
> Dean Jackson wrote:
> > I agree that this causes problems, but it isn't limited to SVG.
> > What does Mozilla do for the Core DOM API?
> 
> At the moment, we throw an exception if an attempt to use the object fails.  In 
> some cases (eg appendChild) this is pretty immediate (since the object probably 
> doesn't expose the internal interfaces needed for managing child lists).  In 
> other cases, (say the node filter argument of createTreeWalker) the exception 
> could be delayed until an attempt to actually use the filter object is made.

These are UA defined exceptions.

> > My suggestion was to throw the error when you know you really
> > don't have something of the right type.
> 
> That makes sense to me.

In that case, unless "correct type" means "the UA's implementation of the
SVG interfaces", Mozilla will NEVER throw SVG_WRONG_TYPE_ERR. Because of
the way XPConnect wraps JavaScript objects, it is impractical for
Mozilla's C++ implementation of SVG to determine whether a JavaScript
object implements the required interfaces (never mind whether the
implementation is correct or not). To do that it would need to test for
each member of the interface(s). In methods that result in an object being
stored it will throw a UA defined exception since the object won't support
the internal interfaces required to store it. (Even if the object could be
stored, doing so without knowing the object implemented the correct
interfaces would risk errors occuring later that could be very difficult
for the SVG author to track down.) If the object is only accessed, then it
will throw what will probably be a UA defined exception if a failure
occurs when trying to access it. 

Jonathan
Received on Wednesday, 11 August 2004 15:41:32 UTC

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