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

Re: a more JavaScripty binding for exceptions

From: Cameron McCormack <cam@mcc.id.au>
Date: Tue, 21 Dec 2010 09:14:12 +1300
To: Ian Hickson <ian@hixie.ch>
Cc: public-script-coord@w3.org
Message-ID: <20101220201412.GA26957@wok.mcc.id.au>
Ian Hickson:
> 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.

I forgot to mention in the original email that you could do this based
on the .name property, since it will contain the exception name (per the
built-in Error types in ECMAScript).  So:

  try {
    // whatever
  } catch (e) {
    if (e.name == "DatabaseConnectionError") {
      // blah

rather than:

  try {
    // whatever
  } catch (e) {
    if (e.code == DBException.DATABASE_CONNECTION_ERR) {
      // blah

These names are necessarily unique, so it is not necessary to check
e instanceof DatabaseConnectionError *and* e.name ==

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

I don’t know where “making it easier for Web platform spec writers to
isolate themselves” lies in the priority of constituencies, but I
suspect designing for consistency with ECMAScript and for authors’ ease-
of-use comes higher.

Note that awareness of what exceptions have been defined in other Web
platform specs is required to avoid collisions in this proposal anyway.
(As with interfaces.)

Cameron McCormack ≝ http://mcc.id.au/
Received on Monday, 20 December 2010 20:14:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:02 UTC