- From: <bugzilla@jessica.w3.org>
- Date: Thu, 13 Oct 2011 05:14:16 +0000
- To: public-script-coord@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10623
Garrett <dhtmlkitchen@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |dhtmlkitchen@gmail.com
--- Comment #17 from Garrett <dhtmlkitchen@gmail.com> 2011-10-13 05:14:15 UTC ---
(In reply to comment #16)
> (In reply to comment #15)
> > I defined something like what you suggested now.
> >
> > http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-throw
> >
> > This should basically allow everyone to mint new DOMException values. When they
> > happen to be one of the types that has a legacy code exception field value code
> > will be set appropriately.
>
> Great!
>
> > Should we have a central registry somewhere (maybe in form of a wiki) where
> > specifications can note additional exception types and descriptions? (They do
> > not need the legacy code field value.)
>
> Yes, I think that is a good idea. Repurpose
> http://wiki.whatwg.org/wiki/Exception_Codes?
>
> One final thing to wonder is whether new exception types (ones that don't have
> a legacy code) should use use Error rather than DOMException.
If you want to keep DOMException, then make its [[Prototype]] be EcmaScript
Error; e.g. -
try {
document.createElement("<<")
} catch(ex) {
alert( ex instanceof Error);
}
- to result true. Keep `ex.code == 5` for legacy reasons.
There are a few benefits to having the thrown object be a standard EcmaScript
Error, as specified by ES. There is no duplication of `message`, `name`,
properties, et al because Error instances have those. And because it is an
Error, there is no specification duplication and no concurrency issues to worry
about.
--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Thursday, 13 October 2011 05:14:28 UTC