23367 2013-09-26 13:47:41 +0000 Move exceptions into IDL 2014-10-04 02:32:46 +0000 1 1 1 Unclassified WebAppsWG WebIDL unspecified PC All RESOLVED FIXED P2 normal --- 25896 23346 24028 1 annevk cam bzbarsky dom erik.arvidsson harald mike public-script-coord travil w3c public-webapps-bugzilla oldest_to_newest 93879 0 annevk 2013-09-26 13:47:41 +0000 DOMException should move into IDL. We should decide whether to harmonize with JavaScript. I can see either having lots of subclasses, which seems like even more pollution, or accepting the platform is a bit different here. DOMError will be removed from the DOM. Returning DOMException from an object is fine. (I thought there was a bug on this, but I could not find it.) 97322 1 annevk 2013-12-09 14:26:45 +0000 *** Bug 24000 has been marked as a duplicate of this bug. *** 99643 2 cam 2014-02-03 22:24:52 +0000 Seems like we should expose it in all globals, too; we have worker APIs that throw DOMExceptions. 109462 3 travil 2014-07-29 06:03:43 +0000 Is the plan to have DOMException subclass Error? Seems like a good idea, any known web-compat issues you can think of? 109463 4 annevk 2014-07-29 06:13:10 +0000 I thought that was already the case by it using "exception" rather than "interface". But yes, and no. 109509 5 erik.arvidsson 2014-07-29 17:21:53 +0000 (In reply to Travis Leithead [MSFT] from comment #3) > Is the plan to have DOMException subclass Error? Seems like a good idea, any > known web-compat issues you can think of? FWIW, Blink and WebKit both have Error.prototype on the prototype chain of DOMExceptions. This change was done maybe 2 years ago. 109510 6 bzbarsky 2014-07-29 18:07:44 +0000 So will Gecko, as of Firefox 32. That's not the same as an actual ES6 subclass, though. 109511 7 erik.arvidsson 2014-07-29 18:15:28 +0000 (In reply to Boris Zbarsky from comment #6) > So will Gecko, as of Firefox 32. That's not the same as an actual ES6 > subclass, though. That is true. We should probably make `DOMException.[[Prototype]] === Error` as well. 112622 8 cam 2014-10-03 05:34:37 +0000 I've removed IDL exception definitions, moved DOMException into the spec (including the table of names and legacy codes), and added types to refer to them -- Error for any exception type (including the native ECMAScript Error objects) and DOMException for just DOMExceptions. I also made DOMException.[[Prototype]] == Error.prototype. https://github.com/heycam/webidl/commit/50e172ec079db073c3724c9beac1b576fb5dbc47 http://heycam.github.io/webidl/#idl-exceptions http://heycam.github.io/webidl/#idl-Error http://heycam.github.io/webidl/#idl-DOMException http://heycam.github.io/webidl/#es-Error http://heycam.github.io/webidl/#es-DOMException http://heycam.github.io/webidl/#es-exceptions http://heycam.github.io/webidl/#es-exception-objects http://heycam.github.io/webidl/#es-creating-throwing-exceptions 112630 9 annevk 2014-10-03 08:37:50 +0000 Excellent, glad to be rid of this: https://github.com/whatwg/dom/commit/7fe5736d3ed2717d71a3d2627b07dee97e10ef05 112672 10 bzbarsky 2014-10-04 02:01:09 +0000 So this made DOMException constructible, right? I'm not opposed to that, but no one implements that right this moment, yes? 112673 11 cam 2014-10-04 02:06:43 +0000 The spec already required it to be constructible before this change. 112674 12 cam 2014-10-04 02:10:56 +0000 But yes I don't think that DOMExceptions are actually constructible in implementations yet. One other thing hidden in this change that maybe I should have called out is that I made "code" a data property on the DOMException instance. 112676 13 bzbarsky 2014-10-04 02:15:33 +0000 Yeah, I did notice that. And message and so forth. 112677 14 cam 2014-10-04 02:32:46 +0000 (In reply to Boris Zbarsky from comment #13) > Yeah, I did notice that. And message and so forth. Cool. Though message was already a data property created during the constructor. https://rawgit.com/heycam/webidl/6c153d257d4640662ee9ba239aa64a806a3845fd/index.html#es-exception-call