Intent to Implement and Ship: DOMException Constructor

[Joshua Bell]

Contact emails

jsb...@chromium.org

Spec

http://heycam.github.io/webidl/#es-DOMException-constructor-object

Note that DOMException used to be defined in the DOM specs, but has migrated out of WHATWG's DOM spec to WebIDL as a fundamental part of the platform.

Summary

var ex = new DOMException(message, opt_name);

Motivation

The primary use case is self-hosting/polyfilling APIs that are specified to throw DOMExceptions. Polyfills use various hacks such as tickling other APIs to get exceptions, or throwing plain Errors or "subclasses" that look like DOMExceptions.

This applies both to synchronous APIs that throw and asynchronous Promise-based APIs, where the TAG recommends that rejections are DOMExceptions: http://www.w3.org/2001/tag/doc/promises-guide#reasons-should-be-errors

Compatibility Risk

Implemented in Gecko/Firefox (in stable builds).

Ongoing technical constraints

None at the moment.

The spec allows for construction without the 'new' operator (like native JS Error objects), which would require bindings changes, but Gecko doesn't support that yet either. The fine details of the spec around properties, prototypes, and so forth aren't matched yet either - DOMException is now defined more like the native JS Error types than other DOM interfaces. We can tackle that over time.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

OWP launch tracking bug?

N/A (really minor - is this worth calling out?)

Link to entry on the feature dashboard

Not added yet, will create one if we go forward with this.

Requesting approval to ship?

Yes - the compat risk is low and we're unlikely to learn anything by leaving this "experimental"

[Boris Zbarsky]

On 7/7/15 7:57 PM, 'Joshua Bell' via blink-dev wrote:
> The spec allows for construction without the 'new' operator

I'm not sure why it does that, honestly. I don't think it should.

Also, either I'm misreading the spec or it just doesn't make any sense
in terms of the sort of object it creates. I filed
https://github.com/heycam/webidl/issues/55 on that part.

> The fine details of the spec around
> properties, prototypes, and so forth aren't matched yet either

Nor in Gecko. We basically just implement it as a Web IDL interface
with a constructor for the moment. It's not clear to me what the
benefits of not doing it that way, and making all browsers change their
implementations, are...

-Boris

[Philip Jägenstedt]

LGTM, I don't think this should be blocked on the differences between defining DOMException using Web IDL and what the spec says, and I've commented on Boris' spec issue.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Domenic Denicola]

From: blin...@chromium.org [mailto:blin...@chromium.org] On Behalf Of Boris Zbarsky

> I'm not sure why it does that, honestly. I don't think it should.
>
> Also, either I'm misreading the spec or it just doesn't make any sense in terms of the sort of object it creates. I filed
> https://github.com/heycam/webidl/issues/55 on that part.

Commented on the issue, but the general gist is that DOMException is trying to be like an ES Error subclass (like TypeError etc.), not like a Web IDL interface.

>> The fine details of the spec around
>> properties, prototypes, and so forth aren't matched yet either
>
> Nor in Gecko. We basically just implement it as a Web IDL interface with a constructor for the moment. It's not clear to me what the benefits of not doing it that way, and making all browsers change their implementations, are...

Consistency with developer expectations, consistency with the language itself, etc. For example a lot of the more naïve Error-reporting code I've seen is designed around serializing own data properties, which defining via a Web IDL interface will not allow.

---

Relatedly, DOMException may be a good target for V8 extras, which could trivially faithfully reproduce the spec. I might take a go at that after some infrastructure issues on V8 extras are worked out (see blocking bugs of https://crbug.com/503491).

[Boris Zbarsky]

On 7/8/15 10:52 AM, Domenic Denicola wrote:
> Commented on the issue, but the general gist is that DOMException is trying to be like an ES Error subclass (like TypeError etc.), not like a Web IDL interface.

Trying but failing, because every single other mention of DOMException
in Web IDL treats it as a platform object, both explicitly in the
definition of DOMException and implicitly in the value conversions,
overload resolution, union type handling, etc.

> Consistency with developer expectations, consistency with the language itself, etc.

OK... let's posit this.

> For example a lot of the more naïve Error-reporting code I've seen is designed around serializing own data properties, which defining via a Web IDL interface will not allow.

Quite apart from the fact that we could extend IDL to allow own data
properties, as we've discussed before anyway, in practice a DOMException
has the following properties that someone might care about and are
supported in all UAs: "code", "name", "message", "stack".

Gecko also has "filename", "lineNumber", "columnNumber", "stack", a
"location" property only visible to privileged code that has an object
representation of the stack, and a few other Gecko-specific things that
I think we could probably get rid of.

Safari has, in addition to the common ones, "line" and "column".

The point of all this is that I strongly feel that of the common ones at
least "stack" should be an accessor: it's expensive to produce the stack
string, both in time and memory, and we should not force UAs to do it
eagerly when an exception is thrown. Chrome does implement "stack" as
an own property, but last I checked it also limits it to 10 frames,
which is pretty suboptimal. Note that there is real-life code out there
(code compiled from Dart, in fact) that depends on stacks either being
size-limited or lazy; see for example
<https://bugzilla.mozilla.org/show_bug.cgi?id=1125259>. Given the
choice between those two options, I would choose "lazy" any time,
because it's not datalossy.

Of course that applies to all Error objects, not just DOMException, so
doesn't preclude DOMException being an Error subclass and Error having
the internal state for storing the data needed to lazily reify the stack
string. My point is that serializing just the own data properties is
not going to give you the stack, at the very least. So the naive
Error-reporting code you've seen is going to have that problem no matter
what.

-Boris

[TAMURA, Kent]

lgtm2

--

TAMURA Kent
Software Engineer, Google

[Alex Russell]

Boris: unless I misunderstand you, it sounds like your desire for `stack` to be an accessor doesn't need to block this as it's generic to all Error types.

[Boris Zbarsky]

On 7/15/15 3:50 AM, Alex Russell wrote:
> Boris: unless I misunderstand you, it sounds like your desire for
> `stack` to be an accessor doesn't need to block this as it's generic to
> all Error types.

That's correct. I'm just pointing out that the desire for all
information on Error types to be own value properties is probably
misguided and should not force us into particular technical solutions
here. There are still other good arguments for making DOMException an
Error subtype.

-Boris

[Chris Harrelson]

LGTM3

-Boris