W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

Re: [WebIDL] Exceptions

From: Aryeh Gregor <Simetrical+w3c@gmail.com>
Date: Thu, 7 Jul 2011 14:41:39 -0400
Message-ID: <CAKA+AxmyPdqecBQZyJ-s+EUjGfE8rRv_z=i_e-06nFmOJXURPw@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Ian Hickson <ian@hixie.ch>, Anne van Kesteren <annevk@opera.com>, WebApps WG <public-webapps@w3.org>
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

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:22 UTC