W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2011

[Bug 10623] Simplify Web IDL exceptions

From: <bugzilla@jessica.w3.org>
Date: Sun, 26 Jun 2011 23:19:10 +0000
To: public-script-coord@w3.org
Message-Id: <E1Qaybe-0001YM-KE@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10623

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

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

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:03 UTC