This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I am trying to create e.g. an IndexedSizeError so as to better match the behavior of native elements, and cannot do so since the DOMException constructor only takes a message, and not a name. Happy to do a PR for this (presumably making the name the second argument) if you agree this is a good idea.
This seems reasonable to me, yeah. I wish we could use this for http://heycam.github.io/webidl/#es-creating-throwing-exceptions too, but ES exceptions do .name based on which constructor you called...
Right, that whole section is largely about why DOMException is a special flower that behaves unlike all the standard ES Error classes :(. Cool, I'll work up a PR.
(In reply to Domenic Denicola from comment #0) > I am trying to create e.g. an IndexedSizeError so as to better match the > behavior of native elements, and cannot do so since the DOMException > constructor only takes a message, and not a name. I'm fine with this, but did you mean you can't do it all, or just not in a single line? var e = new DOMException("..."); e.name = "IndexSizeError"; e.code = 1;
> I'm fine with this, but did you mean you can't do it all, or just not in a single line? You're right; I didn't read far enough to realize that DOMExceptions created using the constructor actually don't have any name or code properties. It doesn't help that the constructor isn't implemented anywhere :). Nevertheless the PR's refactoring gives a nicer solution IMO, both for authors and at a spec level.
https://github.com/w3c/web-platform-tests/pull/1497
This now works, although the spec still needs some rescuing; see https://github.com/heycam/webidl/issues/55