On Thu, Jul 7, 2011 at 2:28 PM, Jonas Sicking <[email protected]> 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.
