a more JavaScripty binding for exceptions

Currently specs tend to use DOMException (or some separate exception
type) with integer exception codes given by constants defined on the
exception.  This isn’t so great:

* it requires coordination for the exception codes used on a given
  exception

* it requires the spec defining the exception to be updated to add
  constants for the new codes

* it’s not very JavaScripty

Here is a proposal for changing this:

* IDL exceptions will be allowed to inherit from other exceptions

* exceptions not declared to inherit from another will inherit from
  the Error prototype in the JS binding

* new specs will define a new IDL exception for each exception to
  define, rather than using DOMException (or a single new exception
  type) and a number of exception codes
  
* in JS, each exception constructor function will take a single argument
  for the exception message, just like the built-in Error objects do

This approach would also make it easier to catch categories of
exceptions, if their hierarchy is defined that way; instead of checking
for various codes in an exception handler, you could do an instanceof
check.

Existing, implemented specs that use exception codes would still have to
work.  We could think about migrating DOMException to multiple exception
types in Web DOM Core with something like this:

  exception DOMException {
    unsigned short code;
  };

  exception HierarchyRequestError : DOMException { };
  exception NoModificationAllowedError : DOMException { }:
  // etc.

Comments welcome on this approach.

-- 
Cameron McCormack ≝ http://mcc.id.au/

Received on Friday, 17 December 2010 18:10:02 UTC