Re: [WebIDL] Exceptions

On Thu, Jul 7, 2011 at 3:47 PM, Ian Hickson <ian@hixie.ch> wrote:
> Anything that allows us to _not_ coordinate is an epic disaster, IMHO.
>
> We absolutely should be coordinating. How else can we ensure the platform
> is a consistent platform?
>
> This is a feature, not a bug.

Maybe, but I still think the .code system is bad:

1) It's excessively verbose.  e.code ==
DOMException.HIERARCHY_REQUEST_ERR is gratuitously hard to type
compared to e.name == "HIERARCHY_REQUEST_ERR".

2) It's harder to debug.  DOMException.HIERARCHY_REQUEST_ERR shows up
in your debugger as 3, which is totally incomprehensible.

3) It clutters every exception object with dozens of useless member
variables that you have to sift through in your debugger.

There's absolutely no reason to use numbers here.  The tendency to use
named constants instead of strings comes from people who write in C or
C++.  They're used to making code harder to write for the sake of
performance.  In C, using a named constant instead of a pointer to a
string might mean you can save ten or more bytes per struct, save a
malloc() on every initialization and a free() on every
deinitialization, test integer equality instead of having to use
strcmp(), switch() on the code, etc.  In JavaScript, none of these
reasons make any sense -- there's just no reason to use named
constants for anything at all.  It's a bad pattern and we should move
away from it.

> My concern is with having newer parts of the platform use entirely
> different models (e.g. new exception interfaces) relative to older parts
> of the platform (which e.g. use codes). It leads to the kind of problem
> you describe with JS vs DOM, except that we'd have JS vs DOM vs new DOM vs
> even new DOM, etc.

I don't think it would lead to much long-term inconsistency if we
don't introduce new codes for new exception types.  Yes, some
exceptions would have a .code attribute and some wouldn't, but that
doesn't strike me as a big deal.  I do agree that we should really be
coordinating here, not having random specs make up new exception types
that aren't added to DOM Core.  For instance, I don't get why we need
FileError and FileException duplicating NOT_FOUND_ERR, SECURITY_ERR,
and ABORT_ERR (with different codes!) from DOMException and adding
NOT_READABLE_ERR and ENCODING_ERR.  Why can't we just add those to
DOMException?

Received on Friday, 8 July 2011 17:07:20 UTC