[Bug 10623] Simplify Web IDL exceptions


--- Comment #8 from Cameron McCormack <cam@mcc.id.au> 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

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.)

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.

Received on Sunday, 26 June 2011 23:19:11 UTC