Re: [WebIDL] Exceptions

On Jul 6, 2011, at 5:05 PM, Jonas Sicking wrote:

> On Wed, Jul 6, 2011 at 2:23 PM, Aryeh Gregor <Simetrical+w3c@gmail.com> wrote:
>> On Wed, Jul 6, 2011 at 7:06 AM, Anne van Kesteren <annevk@opera.com> wrote:
>>> So with Web IDL going to Last Call does this mean that the exception model
>>> outlined in http://www.w3.org/Bugs/Public/show_bug.cgi?id=10623#c8 is the
>>> way forward? I.e. we introduce new exception interfaces in DOM Core for all
>>> the different exception types and update all other specifications that use
>>> DOM Core to dispatch those exceptions instead (and they are somewhat
>>> backwards compatible because they inherit from DOMException and therefore
>>> still have the code member).
>>> 
>>> I guess there is no particular rush on this; I am mainly wondering whether
>>> other editors are aware of this change and agree with it.
>> 
>> The thing I don't like about this proposal is that it encourages
>> authors to use "e instanceof IndexSizeError" or similar.  This will
>> work 98% of the time and then fail in an extremely mysterious way when
>> multiple globals are involved.  All you need is the exception to be
>> thrown by something in an iframe for whatever reason.

You have to remember that exceptions came to JS in ES3, the Third Edition of ECMA-262, and they followed Java's model but without static nominal types. This resulted in the cross-window/frame confusion problem, but ES3 people did not take on specifying multiple globals, and they weren't active multi-window/frame JS hackers, so they missed this.

(Termination-style exception handling doesn't scale anyway, but that's another complaint for another time.)


>> Moreover, I don't even think behavior in that case is defined.  If I
>> call foo.appendChild(bar) and it throws, is the exception from the
>> window where the method was called, or the one foo is associated with,
>> or the one bar is associated with?  Browsers other than Gecko seem to
>> agree it's the one foo is associated with
>> (<http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1064>),
>> and Gecko is just buggy, but is this specced anywhere?  I don't see it
>> in DOM Core.

Gecko is buggy if it is using the dynamic scope. Please file that bug and cc: me.


>> I don't see why we need the extra classes.  What's the advantage over
>> just adding the .name attribute, or something equivalent, and not
>> adding new classes?  Just consistency with ES, or something else too?
> 
> This is indeed a good point. The main reason for me was consistency
> with ES. But I'm not sure why ES was designed the way it is. Generally
> it seems like multiple globals wasn't kept in mind a lot when ES was
> designed, though obviously this is a problem for ES on the web.

See above.


> Would love to hear from ES people that surely has spent more time
> thinking about exceptions than me.

There's nothing deep here. You smell something bad in the design that mixes instanceof and multiple globals, so I agree the best course is to avoid perpetuating it by imitation.

/be

Received on Thursday, 7 July 2011 01:47:40 UTC