W3C home > Mailing lists > Public > public-script-coord@w3.org > October to December 2010

Re: a more JavaScripty binding for exceptions

From: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 20 Dec 2010 12:17:26 -0800
Message-ID: <AANLkTinwLeSPshxj2GxudUrqdUbphqCJePZ9sKCoO4Pd@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: Cameron McCormack <cam@mcc.id.au>, public-script-coord@w3.org
On Mon, Dec 20, 2010 at 11:55 AM, Ian Hickson <ian@hixie.ch> wrote:
> On Sat, 18 Dec 2010, Cameron McCormack wrote:
>>
>> * 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
>
> IMHO using different codes is more important than using different
> interfaces since the usual pattern is just to check e.code in the handler.
> Having to check e.code and the interface type makes things twice as
> complicated.

Getting rid of having to check both .code and interface is exactly
what the proposal is for.

We're currently in the situation that you have to check both .code as
well as the interface. Currently you first have to check the interface
to know if you have a DOMException at all, or if you have for example
a TypeError exception. After that you can check .code.

Additionally at least DOM Events and SVG introduces their own
exceptions with overlapping codes. I'm currently lobbying to make
IndexedDB and FileAPI to not do the same.

In the new proposal all you need to do is to check .name and you're
done with it.

> Having to make sure all the spec writers for Web platform specs
> communicate is *not a bug*. It's absolutely imperative not just for making
> sure exception codes don't overlap (something that really hasn't been much
> of a problem in practice since we have a de-facto registry that we use for
> the purpose) but simply for making sure the platform remains sane! I think
> it would be a mistake to make it easier for Web platform spec writers to
> isolate themselves from the rest of the ecosystem.

Making specs coordinate on error numbers is just creating extra work
for ourselves. It means that we'll have to come to agreements that all
specs should spaces themselves out some N codes apart, as well as come
up with some way of dealing with the situation if a spec needs more
than N codes, possibly by grabbing another block of N codes.

Alternatively set up some sort of registry which is a pain I wouldn't
want to inflict on anyone.

Using strings (in the form of .name and interface names) won't get rid
of the need for coordination, but it makes the coordination much less
painful.

/ Jonas
Received on Monday, 20 December 2010 20:18:20 UTC

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