- From: Brendan Eich <brendan@mozilla.org>
- Date: Wed, 6 Jul 2011 18:46:59 -0700
- To: Jonas Sicking <jonas@sicking.cc>, Aryeh Gregor <Simetrical+w3c@gmail.com>
- Cc: Anne van Kesteren <annevk@opera.com>, WebApps WG <public-webapps@w3.org>, public-script-coord@w3.org
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