This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 10623 - Simplify Web IDL exceptions
Summary: Simplify Web IDL exceptions
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: WebIDL (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Cameron McCormack
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-09-13 07:49 UTC by Anne
Modified: 2011-12-06 05:59 UTC (History)
13 users (show)

See Also:


Attachments

Description Anne 2010-09-13 07:49:06 UTC
I think that all custom exception interfaces defined have been designed after DOMException. I.e. they have a code and that returns the specific type of exception thrown. Maybe we should make things even simpler here in that the specification basically defines a name (e.g. DOMException) and a list of name/number pairs (e.g. INVALID_CHARACTER_ERR/5) and Web IDL handles the rest.
Comment 1 Cameron McCormack 2011-04-12 03:02:29 UTC
Exceptions have been changed so that you can now inherit one from another, with a view to not requiring codes for newly defined exceptions, per <http://www.w3.org/mid/20101217180920.GA31176@wok.mcc.id.au>.  In the simple case for new exceptions where you don't need an inheritance hierarchy for them, you would just write:

  interface MyNewException { };

which will be sufficient for testing against with either `e instanceof MyNewException` or `e.name == "MyNewException"`.
Comment 2 Anne 2011-06-17 13:03:20 UTC
Is it really worth introducing a new model on top of the existing model? That seems to make matters quite a bit more complex and given that legacy APIs will not be changed there is not much benefit. So far we have always opted not to introduce new APIs when there is not much benefit.
Comment 3 Anne 2011-06-17 13:03:47 UTC
Reopening for now.
Comment 4 Cameron McCormack 2011-06-19 00:33:01 UTC
As far as I can tell, we can change the current DOMExceptions to use this mechanism without breaking them.  Integer constant codes suck, both because it's a global namespace of code numbers that requires coordination (which hasn't always happened in the past) and for ease of use for authors.  Whether this is of enough benefit is of course debatable.

I think being able to check `e.name == "ExceptionName"` and for spec authors to be able to mint "ExceptionName"s are the most important parts of the proposal.  If DOM Core authors aren't willing to rework DOMException into a separate IDL exception per type, then we could introduce a way to define e.name in a way that violates the expectation (from ES5's perspective) that it is equal to the constructor object name (i.e. so that it is not just equal to "DOMException" for all kinds of DOMException).

Jonas, do you have any views?
Comment 5 Anne 2011-06-20 13:08:22 UTC
Instead of .name we could also introduce a different attribute if that is the problem. And I think with the new DOM Core coordinating exception codes will be easy. We need to coordinate anyway to ensure some level of consistency.
Comment 6 Brendan Eich 2011-06-20 15:19:03 UTC
Adding a new property instead of .name just kicks the can, and proliferates properties. We have to coordinate on property names now, not values, and users have to discriminate on two properties instead of one.

How about we use public-script-coord, or just this bug, to come up with a scheme to use .name? Just "DOM" as a value-string prefix might be enough.

/be
Comment 7 Anne 2011-06-24 13:38:58 UTC
So how exactly would we change DOMException to use this new model and what would happen to .code checking? (As that is definitely out there.)

I guess I do not really see the problem with minting new constants when needed and adding them to DOMException and just have .name as a convenient checking method. Before having e.name == "SYNTAX_ERR" (where e is a DOMException as it is today) was not deemed problematic, why is it now?
Comment 8 Cameron McCormack 2011-06-26 23:19:09 UTC
(In reply to comment #7)
> So how exactly would we change DOMException to use this new model and what
> would happen to .code checking? (As that is definitely out there.)

My thoughts were that DOM Core would write this:

  exception DOMException {
    const unsigned short INDEX_SIZE_ERR = 1;
    const unsigned short DOMSTRING_SIZE_ERR = 2;
    const unsigned short HIERARCHY_REQUEST_ERR = 3;
    ...

    unsigned short code;
  };

  exception IndexSizeError : DOMException { };
  exception DOMStringSizeError : DOMException { };
  exception HierarchyRequestError : DOMException { };
  ...

and define that when one of the above DOMException-derived exceptions is created, that its code attribute is set to the similarly named constant value.

New exception types would be define with

  exception SuperCoolPlatformError : DOMException { };

but would not get a code minted.

Going forward, you would check the .name of the exception object to discriminate.  .code would still work for the existing exception types.

> I guess I do not really see the problem with minting new constants when needed
> and adding them to DOMException and just have .name as a convenient checking
> method.

1. Using integer constants is kind of awkward.
2. Using .name is necessarily unique, .code isn't.
3. You can use .name to distinguish between built-in JS errors and
   DOMException in the same way.
4. Making .name follow the built-in JS error convention seems like a
   consistency win.

> Before having e.name == "SYNTAX_ERR" (where e is a DOMException as it
> is today) was not deemed problematic, why is it now?

I'm not sure what "before" means in this context.  I would argue (bike-sheddingly) that checking `e.name == "SyntaxError"` is nicer than `e.name == "SYNTAX_ERR"`.

I just realised now though that if we wrote

  exception SyntaxError : DOMException { };

that that would clash with the built-in JS SyntaxError. :/  (We could work around that in a couple of different ways.)
Comment 9 Travis Leithead [MSFT] 2011-07-26 00:03:36 UTC
Anne's original reason for opening this bug appears to be related to simplifying exception definitions for W3C spec authors.

What is the proposal above trying to solve? Is it that we are trying to solve the ambiguity of exception codes?

This seems like a separate "problem" that I've never heard is an actual problem...?
Comment 10 Arun 2011-07-26 19:39:04 UTC
I want to note my enthusiasm for comment #8.  The problems we're trying to solve are:

1. The ongoing tendency to view DOMException as a giant compendium of "things that go bump" in web applications.  I'd rather not do this.

2. Constant value checking, which does go on, but which we can fix or at least mitigate.  

3. Creating "human readable" exception codes in lieu of constants.
Comment 11 Cameron McCormack 2011-07-31 23:07:36 UTC
(In reply to comment #9)
> Anne's original reason for opening this bug appears to be related to
> simplifying exception definitions for W3C spec authors.

The solution I added to the spec wasn't exactly a direct response to Anne's comment 0.  Since the solution was to move away from codes, I resolved it WONTFIX with comment 1.

> What is the proposal above trying to solve? Is it that we are trying to solve
> the ambiguity of exception codes?

* resolving potential ambiguity of exception codes
* making exception type discrimination simpler for authors and bringing DOM exceptions more into line with JS exceptions were the aims of the proposal.

> This seems like a separate "problem" that I've never heard is an actual
> problem...?

The ambiguity yes, I will admit it is more of a theoretical problem.
Comment 12 Anne 2011-08-02 08:35:42 UTC
I think if we give authors the ability to do

  e.name == "SYNTAX_ERR"

or maybe an alternative attribute that gives a string people prefer that would be sufficient. Minting new codes and exceptions is hardly problematic.
Comment 13 Anne 2011-08-18 13:58:45 UTC
The platform already shares exceptions all over so maybe we should converge on that by having everything on exceptions in Web IDL. The only thing other specifications would do is say "throw a SYNTAX_ERR exception" or some such.

Just like Web IDL now defines DOMString and DOMTimeStamp, Web IDL would define DOMException and be responsible for maintaining it (potentially having some way for specifications to add to it, but I think if we revise Web IDL every now and then we should be fine). Other specifications just need to dispatch the appropriate exception defined by Web IDL. For most of the DOM platform we have already found ways to converge on DOMException. I do not think it should be problematic if we continue this trend through the whole platform.
Comment 14 Cameron McCormack 2011-09-09 12:30:43 UTC
I've had another crack at exceptions.  There is no recommendation in the spec now to create a hierarchy of exceptions.  Instead it recommends to use DOMException for all new exception types, or to mint a new IDL exception only if new exception fields are required.  IDL exceptions now conceptually have a "type", which gets mapped on to the .name property in JS.  So you could say

  Throw a DOMException of type "FooBarError".

and that would result in a DOMException object whose .name == "FooBarError".  You can not specify the type, in which case .name == "DOMException" (so the name of the constructor is the .name of the exception, like the builtin JS ones).

There's no IDL syntax for defining exception types like "FooBarError" above; just do this in prose.

Jonas, Alex and I had some offlist discussions about whether we could do away with DOMException altogether and just use Error.  I think some experiments were going to be done to see if this is feasible.  I am happy for now using DOMException.

Comments welcome.  Perhaps start a thread on public-script-coord if there are issues with this approach.  I will declare this Last Call comment resolved at this point, however.  Anne, please indicate whether this resolution is satisfactory.

See the exact change here:

http://dev.w3.org/cvsweb/2006/webapi/WebIDL/Overview.html.diff?r1=1.397;r2=1.398;f=h
Comment 15 Anne 2011-09-26 09:09:33 UTC
I defined something like what you suggested now.

http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-throw

This should basically allow everyone to mint new DOMException values. When they happen to be one of the types that has a legacy code exception field value code will be set appropriately.

Should we have a central registry somewhere (maybe in form of a wiki) where specifications can note additional exception types and descriptions? (They do not need the legacy code field value.)
Comment 16 Cameron McCormack 2011-10-13 04:09:07 UTC
(In reply to comment #15)
> I defined something like what you suggested now.
> 
> http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-throw
> 
> This should basically allow everyone to mint new DOMException values. When they
> happen to be one of the types that has a legacy code exception field value code
> will be set appropriately.

Great!

> Should we have a central registry somewhere (maybe in form of a wiki) where
> specifications can note additional exception types and descriptions? (They do
> not need the legacy code field value.)

Yes, I think that is a good idea.  Repurpose http://wiki.whatwg.org/wiki/Exception_Codes?

One final thing to wonder is whether new exception types (ones that don't have a legacy code) should use use Error rather than DOMException.
Comment 17 Garrett 2011-10-13 05:14:15 UTC
(In reply to comment #16)
> (In reply to comment #15)
> > I defined something like what you suggested now.
> > 
> > http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-throw
> > 
> > This should basically allow everyone to mint new DOMException values. When they
> > happen to be one of the types that has a legacy code exception field value code
> > will be set appropriately.
> 
> Great!
> 
> > Should we have a central registry somewhere (maybe in form of a wiki) where
> > specifications can note additional exception types and descriptions? (They do
> > not need the legacy code field value.)
> 
> Yes, I think that is a good idea.  Repurpose
> http://wiki.whatwg.org/wiki/Exception_Codes?
> 
> One final thing to wonder is whether new exception types (ones that don't have
> a legacy code) should use use Error rather than DOMException.
If you want to keep DOMException, then make its [[Prototype]] be EcmaScript Error; e.g. -

 try { 
   document.createElement("<<") 
 } catch(ex) { 
   alert( ex instanceof Error);
 }

- to result true. Keep `ex.code == 5` for legacy reasons.

There are a few benefits to having the thrown object be a standard EcmaScript Error, as specified by ES. There is no duplication of `message`, `name`, properties, et al because Error instances have those. And because it is an Error, there is no specification duplication and no concurrency issues to worry about.
Comment 18 Cameron McCormack 2011-10-13 05:34:25 UTC
Yep, that should already be the case per http://dev.w3.org/2006/webapi/WebIDL/#es-exception-interface-prototype-object.
Comment 19 Anne 2011-10-19 04:54:44 UTC
I think it's easiest if we use Error for binding exceptions and DOMException for API exceptions.

For now we agreed that DOM4 would be updated with new exceptions whenever people minted them. The procedure is filing a bug or sending an email requesting the string is included in DOM4. If that turns out to be problematic we should look into the wiki idea I guess.
Comment 20 Cameron McCormack 2011-10-20 21:02:51 UTC
(In reply to comment #19)
> I think it's easiest if we use Error for binding exceptions and DOMException
> for API exceptions.

I don't understand the distinction between "exceptions" and "API exceptions" here.

> For now we agreed that DOM4 would be updated with new exceptions whenever
> people minted them. The procedure is filing a bug or sending an email
> requesting the string is included in DOM4. If that turns out to be problematic
> we should look into the wiki idea I guess.

OK.
Comment 21 Cameron McCormack 2011-12-06 05:59:53 UTC
I don't think there are any actionable requests for changes left in this bug.  Please reopen if I've got it wrong.