Re: a more JavaScripty binding for exceptions

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

> 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