[Bug 14376] Move to the new WebIDL exceptions

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=14376

Ms2ger  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #1 from Ms2ger  2012-08-25 18:28:48 UTC ---
https://bitbucket.org/ms2ger/dom-parsing-and-serialization/changeset/a253d406e3cf02be45d2531bf8891512

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 14376] New: Move to the new WebIDL exceptions

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=14376

   Summary: Move to the new WebIDL exceptions
   Product: WebAppsWG
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: DOM Parsing and Serialization
AssignedTo: ms2...@gmail.com
ReportedBy: ms2...@gmail.com
 QAContact: member-webapi-...@w3.org
CC: m...@w3.org, public-webapps@w3.org




-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

Re: [WebIDL] Exceptions

[Ian Hickson]

On Fri, 8 Jul 2011, Robin Berjon wrote:
> On Jul 8, 2011, at 21:56 , Ian Hickson wrote:
> > On Fri, 8 Jul 2011, Robin Berjon wrote:
> >> 
> >> Obviously we should coordinate, but coordination is time-consuming.
> > 
> > Coordinating exceptions codes is just a matter of checking a wiki 
> > page. It's hardly time-consuming.
> 
> It only takes one person to forget to screw things up. And screw up we 
> have. If there were a technical advantage to codes I might be receptive 
> to your arguments, but there isn't. We can make everything both 
> consistent and more usable with names. 
> http://berjon.com/blog/2011/06/numerical-constants-must-die.html

I'm not arguing for codes. We'll need coordination with names too.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [WebIDL] Exceptions

[Aryeh Gregor]

On Fri, Jul 8, 2011 at 3:56 PM, Ian Hickson  wrote:
> If the proposal is to make all exceptions have a "name" property (or
> whatever we call it) whether in ES, in DOM, or anywhere else, and to have
> everyone pick consistent exception names, then I'm fine with that. If we
> do do that then I'd still say we should just have one exception interface
> object, or at least no more objects than we have today, purely because
> there would be no advantage to having more in such a situation.

I think this is the proposal as it stands, yes.  I don't *think*
anyone participating in this discussion supports adding new interfaces
for every exception type at this point.

> Exactly. This is the kind of problem that occurs if we can avoid
> coordination. We shouldn't avoid coordination.
>
> Authors don't care that there's six working groups or twelve. They just
> have one platform they're authoring to. We need to act like one.

Agreed.

Re: [WebIDL] Exceptions

[Robin Berjon]

On Jul 8, 2011, at 21:56 , Ian Hickson wrote:
> On Fri, 8 Jul 2011, Robin Berjon wrote:
>> 
>> Obviously we should coordinate, but coordination is time-consuming.
> 
> Coordinating exceptions codes is just a matter of checking a wiki page. 
> It's hardly time-consuming.

It only takes one person to forget to screw things up. And screw up we have. If 
there were a technical advantage to codes I might be receptive to your 
arguments, but there isn't. We can make everything both consistent and more 
usable with names. 
http://berjon.com/blog/2011/06/numerical-constants-must-die.html

>> We shouldn't set ourselves up in such a way that we need to coordinate 
>> over every last detail ˜ some things should be such that they just work, 
>> without requiring WebApps, HTML, DAP, Web Notifications, CSS, Web 
>> Performance, WHAT, MAWG, RDF WebApps, SVG, Geolocation, and several I'm 
>> forgetting about to all talk together.
> 
> A huge part of the problem here is we have too many groups in the first 
> place.

I heartily agree, I think we'd be better off with a monster Web APIs group (and 
companies that want APIs fenced off to smaller groups over IP concerns can bite 
my shiny WebIDL). But every time groups with a large number of deliverables 
like DAP or WebApps get rechartered, we get feedback, usually from Big Web, 
that they have too many deliverables so I'm not sure how to address this. Back 
when XML was all the rage, and there were many groups using or developing 
around it, there was the XML Plenary that was supposed to be the channel for 
everyone to talk together. I don't think it worked all that well though.

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Re: [WebIDL] Exceptions

[Ian Hickson]

On Thu, 7 Jul 2011, Jonas Sicking wrote:
> On Thu, Jul 7, 2011 at 12:47 PM, Ian Hickson  wrote:
> > On Thu, 7 Jul 2011, Jonas Sicking wrote:
> >>
> >> It's a pain since it forces us to try to coordinate codes across 
> >> multiple specifications, working groups and standards organizations.
> >
> > Anything that allows us to _not_ coordinate is an epic disaster, IMHO.
> >
> > We absolutely should be coordinating. How else can we ensure the 
> > platform is a consistent platform?
> >
> > This is a feature, not a bug.
> 
> Ok, let me know once this has been resolved and we can remove this from 
> the list of arguments at that time.

That we are not coordinating well today is not a valid argument for making 
it easier for us to not coordinate, IMHO.


> > Are there exceptions that can be legitimately thrown by JS that aren't 
> > programming bugs?
> 
> Don't know. Are there ones that can be thrown by the DOM that aren't 
> programming bugs?

Sure, QUOTA_EXCEEDED_ERR, for instance. But I take your point.


> > My concern is with having newer parts of the platform use entirely 
> > different models (e.g. new exception interfaces) relative to older 
> > parts of the platform (which e.g. use codes). It leads to the kind of 
> > problem you describe with JS vs DOM, except that we'd have JS vs DOM 
> > vs new DOM vs even new DOM, etc.
> 
> This is an attempt to fix this problem. We're already in the state where 
> we have two different exception systems. This is an attempt to create 
> just one. The one used by ES. I'm definitely not suggesting that the 
> existing exceptions thrown by various specs should *not* have a .name 
> and should not inherit Exception. I think all exceptions should be 
> changed to follow that model.

I support anything that makes the platform more consistent. My impression 
was that the proposals so far would make the platform less consistent, by 
having some exceptions caught based on their type (instanceof TypeError), 
and some by their code (.code == Exception.SYNTAX_ERR).

If the proposal is to make all exceptions have a "name" property (or 
whatever we call it) whether in ES, in DOM, or anywhere else, and to have 
everyone pick consistent exception names, then I'm fine with that. If we 
do do that then I'd still say we should just have one exception interface 
object, or at least no more objects than we have today, purely because 
there would be no advantage to having more in such a situation. (I'd also 
suggest we keep giving exceptions codes, so that there aren't some 
exceptions that use codes and others that only have a name, but that's not 
a big deal.)


On Fri, 8 Jul 2011, Robin Berjon wrote:
> 
> Obviously we should coordinate, but coordination is time-consuming.

Coordinating exceptions codes is just a matter of checking a wiki page. 
It's hardly time-consuming.


> We shouldn't set ourselves up in such a way that we need to coordinate 
> over every last detail � some things should be such that they just work, 
> without requiring WebApps, HTML, DAP, Web Notifications, CSS, Web 
> Performance, WHAT, MAWG, RDF WebApps, SVG, Geolocation, and several I'm 
> forgetting about to all talk together.

A huge part of the problem here is we have too many groups in the first 
place.


On Fri, 8 Jul 2011, Aryeh Gregor wrote:
> 
> I still think the .code system is bad

I'm not arguing in favour of .code.


> For instance, I don't get why we need FileError and FileException 
> duplicating NOT_FOUND_ERR, SECURITY_ERR, and ABORT_ERR (with different 
> codes!) from DOMException and adding NOT_READABLE_ERR and ENCODING_ERR.  
> Why can't we just add those to DOMException?

Exactly. This is the kind of problem that occurs if we can avoid 
coordination. We shouldn't avoid coordination.

Authors don't care that there's six working groups or twelve. They just 
have one platform they're authoring to. We need to act like one.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [WebIDL] Exceptions

[Aryeh Gregor]

On Thu, Jul 7, 2011 at 3:47 PM, Ian Hickson  wrote:
> Anything that allows us to _not_ coordinate is an epic disaster, IMHO.
>
> We absolutely should be coordinating. How else can we ensure the platform
> is a consistent platform?
>
> This is a feature, not a bug.

Maybe, but I still think the .code system is bad:

1) It's excessively verbose.  e.code ==
DOMException.HIERARCHY_REQUEST_ERR is gratuitously hard to type
compared to e.name == "HIERARCHY_REQUEST_ERR".

2) It's harder to debug.  DOMException.HIERARCHY_REQUEST_ERR shows up
in your debugger as 3, which is totally incomprehensible.

3) It clutters every exception object with dozens of useless member
variables that you have to sift through in your debugger.

There's absolutely no reason to use numbers here.  The tendency to use
named constants instead of strings comes from people who write in C or
C++.  They're used to making code harder to write for the sake of
performance.  In C, using a named constant instead of a pointer to a
string might mean you can save ten or more bytes per struct, save a
malloc() on every initialization and a free() on every
deinitialization, test integer equality instead of having to use
strcmp(), switch() on the code, etc.  In JavaScript, none of these
reasons make any sense -- there's just no reason to use named
constants for anything at all.  It's a bad pattern and we should move
away from it.

> My concern is with having newer parts of the platform use entirely
> different models (e.g. new exception interfaces) relative to older parts
> of the platform (which e.g. use codes). It leads to the kind of problem
> you describe with JS vs DOM, except that we'd have JS vs DOM vs new DOM vs
> even new DOM, etc.

I don't think it would lead to much long-term inconsistency if we
don't introduce new codes for new exception types.  Yes, some
exceptions would have a .code attribute and some wouldn't, but that
doesn't strike me as a big deal.  I do agree that we should really be
coordinating here, not having random specs make up new exception types
that aren't added to DOM Core.  For instance, I don't get why we need
FileError and FileException duplicating NOT_FOUND_ERR, SECURITY_ERR,
and ABORT_ERR (with different codes!) from DOMException and adding
NOT_READABLE_ERR and ENCODING_ERR.  Why can't we just add those to
DOMException?

Re: [WebIDL] Exceptions

[Robin Berjon]

On Jul 7, 2011, at 21:47 , Ian Hickson wrote:
> On Thu, 7 Jul 2011, Jonas Sicking wrote:
>> 
>> It's a pain since it forces us to try to coordinate codes across
>> multiple specifications, working groups and standards organizations.
> 
> Anything that allows us to _not_ coordinate is an epic disaster, IMHO.
> 
> We absolutely should be coordinating. How else can we ensure the platform 
> is a consistent platform?
> 
> This is a feature, not a bug.

Obviously we should coordinate, but coordination is time-consuming. We 
shouldn't set ourselves up in such a way that we need to coordinate over every 
last detail — some things should be such that they just work, without requiring 
WebApps, HTML, DAP, Web Notifications, CSS, Web Performance, WHAT, MAWG, RDF 
WebApps, SVG, Geolocation, and several I'm forgetting about to all talk 
together.

Having to coordinate over whether your exception code should be 17 or 42 is a 
waste of time, time best spent on coordinating over issues that actually 
matter. It's also too easy to overlook. We've shot ourselves in the feet 
repeatedly with this one, a change wouldn't hurt.

>> Lastly, the syntax:
>> if (ex.name === "HierarchyRequestError") { ... }
>> is a lot easier on the eyes than:
>> if (ex.code === DOMException.HIERARCHY_REQUEST_ERR) { ... }
>> IMHO.
> 
> I've no problem with adding names to all the current exceptions, if we 
> want to do that. (I generally am averse to using strings for values, since 
> they don't syntax check well, but in JS that game is somewhat lost in the 
> above scenario anyway, so whatever.)

Yeah, it's completely lost in JS, if you typo either of the above variants they 
both fail silently.

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Re: [WebIDL] Exceptions

[Jonas Sicking]

On Thu, Jul 7, 2011 at 12:47 PM, Ian Hickson  wrote:
> On Thu, 7 Jul 2011, Jonas Sicking wrote:
>>
>> It's a pain since it forces us to try to coordinate codes across
>> multiple specifications, working groups and standards organizations.
>
> Anything that allows us to _not_ coordinate is an epic disaster, IMHO.
>
> We absolutely should be coordinating. How else can we ensure the platform
> is a consistent platform?
>
> This is a feature, not a bug.

Ok, let me know once this has been resolved and we can remove this
from the list of arguments at that time.

>> And even if this coordinating somehow started magically working, it
>> still means that exceptions thrown by the DOM needs to be checked
>> differently than exceptions thrown by ES. So you'll end up having to do:
>
> Are there exceptions that can be legitimately thrown by JS that aren't
> programming bugs?

Don't know. Are there ones that can be thrown by the DOM that aren't
programming bugs?

>> Lastly, the syntax:
>> if (ex.name === "HierarchyRequestError") { ... }
>> is a lot easier on the eyes than:
>> if (ex.code === DOMException.HIERARCHY_REQUEST_ERR) { ... }
>> IMHO.
>
> I've no problem with adding names to all the current exceptions, if we
> want to do that. (I generally am averse to using strings for values, since
> they don't syntax check well, but in JS that game is somewhat lost in the
> above scenario anyway, so whatever.)
>
> My concern is with having newer parts of the platform use entirely
> different models (e.g. new exception interfaces) relative to older parts
> of the platform (which e.g. use codes). It leads to the kind of problem
> you describe with JS vs DOM, except that we'd have JS vs DOM vs new DOM vs
> even new DOM, etc.

This is an attempt to fix this problem. We're already in the state
where we have two different exception systems. This is an attempt to
create just one. The one used by ES. I'm definitely not suggesting
that the existing exceptions thrown by various specs should *not* have
a .name and should not inherit Exception. I think all exceptions
should be changed to follow that model.

/ Jonas

Re: [WebIDL] Exceptions

[Ian Hickson]

On Thu, 7 Jul 2011, Jonas Sicking wrote:
> 
> It's a pain since it forces us to try to coordinate codes across
> multiple specifications, working groups and standards organizations.

Anything that allows us to _not_ coordinate is an epic disaster, IMHO.

We absolutely should be coordinating. How else can we ensure the platform 
is a consistent platform?

This is a feature, not a bug.


> And even if this coordinating somehow started magically working, it 
> still means that exceptions thrown by the DOM needs to be checked 
> differently than exceptions thrown by ES. So you'll end up having to do:

Are there exceptions that can be legitimately thrown by JS that aren't 
programming bugs?


> Lastly, the syntax:
> if (ex.name === "HierarchyRequestError") { ... }
> is a lot easier on the eyes than:
> if (ex.code === DOMException.HIERARCHY_REQUEST_ERR) { ... }
> IMHO.

I've no problem with adding names to all the current exceptions, if we 
want to do that. (I generally am averse to using strings for values, since 
they don't syntax check well, but in JS that game is somewhat lost in the 
above scenario anyway, so whatever.)

My concern is with having newer parts of the platform use entirely 
different models (e.g. new exception interfaces) relative to older parts 
of the platform (which e.g. use codes). It leads to the kind of problem 
you describe with JS vs DOM, except that we'd have JS vs DOM vs new DOM vs 
even new DOM, etc.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [WebIDL] Exceptions

[Aryeh Gregor]

On Thu, Jul 7, 2011 at 2:28 PM, Jonas Sicking  wrote:
> It's a pain since it forces us to try to coordinate codes across
> multiple specifications, working groups and standards organizations.
> So far this has failed resulting in multiple specifications defining
> their own exception types with overlapping codes, forcing people to
> check both interface and code. I strongly suspect there's tons of
> "buggy" JS code out there that doesn't do this correctly and just
> checks the code.
>
> So while in theory using codes to distinguish could work, in practice it 
> hasn't.

I think (?) everyone agrees codes are a bad idea for new exceptions,
and we should add a .name attribute that contains the exception name
and use that instead.  The question is whether we should also define
different interfaces for each exception, or just make everything a
DOMException or whatever.  I see no advantage to adding the extra
interfaces, if we want authors to check .name instead of using
instanceof.

A separate issue is, if we use .name, what exactly it should contain.
"HierarchyRequestError" would look more like ES exceptions, but some
existing browsers support .name and have it contain
"HIERARCHY_REQUEST_ERROR" or something similar.  This is a bikeshed
issue, but I'd say pave the cowpaths and format the error code
LIKE_THIS instead of LikeThis for DOMExceptions and friends, even
though it's inconsistent with TypeError and such.

Re: [WebIDL] Exceptions

[Jonas Sicking]

On Wed, Jul 6, 2011 at 9:04 PM, Ian Hickson  wrote:
> On Wed, 6 Jul 2011, Aryeh Gregor wrote:
>>
>> 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.
>
> I'm also skeptical of this. The platform uses DOMException almost
> everywhere, and I really don't see what's wrong with that.

It's a pain since it forces us to try to coordinate codes across
multiple specifications, working groups and standards organizations.
So far this has failed resulting in multiple specifications defining
their own exception types with overlapping codes, forcing people to
check both interface and code. I strongly suspect there's tons of
"buggy" JS code out there that doesn't do this correctly and just
checks the code.

So while in theory using codes to distinguish could work, in practice it hasn't.

And even if this coordinating somehow started magically working, it
still means that exceptions thrown by the DOM needs to be checked
differently than exceptions thrown by ES. So you'll end up having to
do:

switch (ex.code) {
  case DOMException.HIERARCHY_REQUEST_ERR:
   ...
  case DOMException.WRONG_DOCUMENT_ERR:
   ...
  default:
   switch (ex.name) {
 case "TypeError":
...
   }
}

Lastly, the syntax:
if (ex.name === "HierarchyRequestError") { ... }
is a lot easier on the eyes than:
if (ex.code === DOMException.HIERARCHY_REQUEST_ERR) { ... }
IMHO.

/ Jonas

Re: [WebIDL] Exceptions

[Brendan Eich]

On Jul 7, 2011, at 10:09 AM, Aryeh Gregor wrote:

> On Wed, Jul 6, 2011 at 9:46 PM, Brendan Eich  wrote:
>> Gecko is buggy if it is using the dynamic scope. Please file that bug and 
>> cc: me.
> 
> Gecko says the exception is an instanceof the DOMException object that
> corresponds to *any* window.  So e instanceof window1.DOMException and
> also e instanceof window2.DOMException.  IIRC, there's already a bug
> filed on this, but I can't find it.

Oh, I dimly recall this now. Earl adaptation to help developers confused by the 
cross-frame instanceof failure case? Not sure how early but I think it's pretty 
old.

If you use Object.getPrototypeOf in a loop (hand-expand instanceof), you can 
probably find out which window's DOMException.prototype is on the chain. That 
would be interesting.

/be

Re: [WebIDL] Exceptions

[Aryeh Gregor]

On Wed, Jul 6, 2011 at 9:46 PM, Brendan Eich  wrote:
> Gecko is buggy if it is using the dynamic scope. Please file that bug and cc: 
> me.

Gecko says the exception is an instanceof the DOMException object that
corresponds to *any* window.  So e instanceof window1.DOMException and
also e instanceof window2.DOMException.  IIRC, there's already a bug
filed on this, but I can't find it.

Re: [WebIDL] Exceptions

[Ian Hickson]

On Wed, 6 Jul 2011, Aryeh Gregor wrote:
>
> 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.

I'm also skeptical of this. The platform uses DOMException almost 
everywhere, and I really don't see what's wrong with that.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [WebIDL] Exceptions

[John J. Barton]

On 7/6/2011 6:06 PM, Allen Wirfs-Brock wrote:


I'd much prefer to see code that looks like:
  try {doSomeDOMStuff() }
  catch (e) {
 switch (e.name) {
  case "NoNotificationAllowedError": ...; break;
  case "HierarchyRequestError": ...; break;
  default: throw e
   }
  }
Any work with DOM API (at least in Firefox) makes even this case 
impractical.  You'll be luck if the exception has *any* meaningful content.


jjb

Re: [WebIDL] Exceptions

[Brendan Eich]

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

> On Wed, Jul 6, 2011 at 2:23 PM, Aryeh Gregor  wrote:
>> On Wed, Jul 6, 2011 at 7:06 AM, Anne van Kesteren  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
>> (),
>> 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

Re: [WebIDL] Exceptions

[Allen Wirfs-Brock]

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

> On Wed, Jul 6, 2011 at 2:23 PM, Aryeh Gregor  wrote:
>> On Wed, Jul 6, 2011 at 7:06 AM, Anne van Kesteren  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.
>> 
>> 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
>> (),
>> and Gecko is just buggy, but is this specced anywhere?  I don't see it
>> in DOM Core.
>> 
>> 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.
> 
> Would love to hear from ES people that surely has spent more time
> thinking about exceptions than me.
> 
> / Jonas
> 


From an Object-oriented design perspective I always discourage use of 
instanceof tests.  The problem mentioned here by a Aryeh is a good example why, 
you may have semantically equivalent objects that are instances of different 
"classes" in different hierarchies.  This is particularly true for dynamic 
languages such as ES.  Given that DOM Core is explicitly an environment that 
provides multiple global objects (and hence multiple semantically equivalent 
objects) it seems particularly unwise for it to depend upon or even recommend 
using such tests. 

ECMAScript itself does not have a very rich set of exception "classes" and its 
hierarchy is essentially flat. If you ignore instanceof testing then all the 
specialized exception constructors (TypeError, RangeError, ReferenceError, 
etc.) really provide is the ability to say:
 throw RangeError("my message");
instead of
 var excpt = Error("my message");
 excpt.name = "RangeError";
 throw excpt;
In other words, a more concise way to set the name property of a new exception 
that is about to be thrown.  Given that the various DOMErrors are thrown by the 
DOM implementation, I don't think that ease of throwing is a relevant issues. 

As a further point of reference I've designed several exception hierarchies for 
a couple of languages and used them in many others.  My experience is that 
while some developers love to put time into designing elaborate hierarchies of 
exceptions, in practice hierarchical exception structures are seldom exploited 
by actual application code. A few flat exceptions are more useful then a 
complex hierarchy that nobody ever remembers.

In the case of the the DOM I think a single exception type where different 
kinds of exceptions are discriminated by their name property would be much 
better then a bunch of frame dependent exception constructors.

I'd much prefer to see code that looks like:
 try {doSomeDOMStuff() }
 catch (e) {
switch (e.name) {
 case "NoNotificationAllowedError": ...; break;
 case "HierarchyRequestError": ...; break;
 default: throw e
  }
 }

 rather than:

 try {doSomeDOMStuff() }
 catch (e) {
if (e instanceof NoNotificationAllowError) {...}
else if (e instanceof HierarchyRequestError) {...}
   else throw e;
 }

The latter invites cross-frame multiple global issues.  The former is totally 
immune to them. 

Re: [WebIDL] Exceptions

[Jonas Sicking]

On Wed, Jul 6, 2011 at 2:23 PM, Aryeh Gregor  wrote:
> On Wed, Jul 6, 2011 at 7:06 AM, Anne van Kesteren  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.
>
> 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
> (),
> and Gecko is just buggy, but is this specced anywhere?  I don't see it
> in DOM Core.
>
> 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.

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

/ Jonas

Re: [WebIDL] Exceptions

[Aryeh Gregor]

On Wed, Jul 6, 2011 at 7:06 AM, Anne van Kesteren  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.

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
(),
and Gecko is just buggy, but is this specced anywhere?  I don't see it
in DOM Core.

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?

Re: [WebIDL] Exceptions

[Jonas Sicking]

On Wed, Jul 6, 2011 at 4:06 AM, Anne van Kesteren  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.

I absolutely think this is the way forward. I hope to get IndexedDB
updated before it goes to last call.

/ Jonas

[WebIDL] Exceptions

[Anne van Kesteren]

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.



--
Anne van Kesteren
http://annevankesteren.nl/

Re: WebIDL exceptions

[Darin Adler]

There seems to be some coverage of this here 
. It specifically 
calls for the [[Prototype]] of Object.prototype.

-- Darin

WebIDL exceptions

[Andrew Oakley]

Is there any agreement on how exceptions in WebIDL should map to
ECMAScript objects?  I can't see anything in WebIDL to specify this.

I would have expected each exception type to have an interface object
and an interface prototype object, both containing the constants for the
exception numbers.  The interface prototype objects would all inherit
from the same thing (I used DOMException but ACID3 implies this is
incorrect).  This object would then implement toString for exceptions.
Inheriting from the ECMAScript Error.prototype object would also seem
reasonable.

My understanding of the current browser implementation is that in Gecko
and Webkit browsers the interface prototype objects have
Object.prototype as their [[Prototype]].  Opera doesn't seem to have
interface prototype objects for exceptions.

I would propose that the right thing to say in WebIDL is that exception
interface and interface prototype objects are constructed in the same
manner as normal interfaces, and that the interface prototype objects
have the Object.prototype object as their [[Prototype]] unless something
else is indicated in the IDL.

Does this seem right, or am I barking up the wrong tree?

-- 
Andrew Oakley