Re: [WebIDL] Exceptions

On Thu, Jul 7, 2011 at 2:28 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> It's a pain since it forces us to try to coordinate codes across
> multiple specifications, working groups and standards organizations.
> So far this has failed resulting in multiple specifications defining
> their own exception types with overlapping codes, forcing people to
> check both interface and code. I strongly suspect there's tons of
> "buggy" JS code out there that doesn't do this correctly and just
> checks the code.
>
> So while in theory using codes to distinguish could work, in practice it hasn't.

I think (?) everyone agrees codes are a bad idea for new exceptions,
and we should add a .name attribute that contains the exception name
and use that instead.  The question is whether we should also define
different interfaces for each exception, or just make everything a
DOMException or whatever.  I see no advantage to adding the extra
interfaces, if we want authors to check .name instead of using
instanceof.

A separate issue is, if we use .name, what exactly it should contain.
"HierarchyRequestError" would look more like ES exceptions, but some
existing browsers support .name and have it contain
"HIERARCHY_REQUEST_ERROR" or something similar.  This is a bikeshed
issue, but I'd say pave the cowpaths and format the error code
LIKE_THIS instead of LikeThis for DOMExceptions and friends, even
though it's inconsistent with TypeError and such.

Received on Thursday, 7 July 2011 18:42:26 UTC