This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.)
*** Bug 24000 has been marked as a duplicate of this bug. ***
Seems like we should expose it in all globals, too; we have worker APIs that throw DOMExceptions.
Is the plan to have DOMException subclass Error? Seems like a good idea, any known web-compat issues you can think of?
I thought that was already the case by it using "exception" rather than "interface". But yes, and no.
(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.
So will Gecko, as of Firefox 32. That's not the same as an actual ES6 subclass, though.
(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.
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
Excellent, glad to be rid of this: https://github.com/whatwg/dom/commit/7fe5736d3ed2717d71a3d2627b07dee97e10ef05
So this made DOMException constructible, right? I'm not opposed to that, but no one implements that right this moment, yes?
The spec already required it to be constructible before this change.
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.
Yeah, I did notice that. And message and so forth.
(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