- From: Aryeh Gregor <Simetrical+w3c@gmail.com>
- Date: Thu, 7 Jul 2011 14:41:39 -0400
- 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 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