Intent to Implement and Ship: Replace use of DOMError with DOMException in IndexedDB

[Joshua Bell]

Contact emails

jsb...@chromium.org, phi...@opera.com

Spec

https://w3c.github.io/IndexedDB/ (Editor's Draft; but I'm the editor so...)

https://dom.spec.whatwg.org/#dom-core-changes

Summary

Replace uses of DOMError (present in `error` attributes) with DOMException

Motivation

We'd like to drop DOMError from the platform, as it is redundant with DOMException. Promises that reject already yield DOMExceptions. A handful of specs surface DOMError types, with IndexedDB being one of them. So... let's start with IndexedDB.

DOMError instances have a `name` attribute (one of the strings defined in specs like WebIDL) and `message` attribute (browser specific, striving to explain the issue)

DOMException instances have a `name` (ditto) and `message` (ditto), as well as a legacy `code`.

So DOMExceptions are a drop-in replacement as far as consumers are concerned.

Compatibility Risk

Since the types have the same attributes, the following will not break:

if (request.error.name === 'ConstraintError') ...

log_to_server(transaction.error.name, transaction.error.message);

And since we're not talking about removing the DOMError constructor, this will still work:

var myerr = new DOMError('name', 'message');

That said, this code would start failing:

if (request.error instanceof DOMError) ...

Blink didn't have any layout tests for this - oops! (Most of the tests were written when errors were reported as a pair of attributes, they were wrapped as a type later.) A quick of github shows a few instances of test code for shims, but I didn't find anything that would break;

Ongoing technical constraints

This does put slightly more onus on us to implement the DOMException constructor in order to allow polyfills, but that was the case already. Otherwise: None.

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 - if anyone will actually notice this we probably can't make this change.

Link to entry on the feature dashboard

N/A

Requesting approval to ship?

Yep.

[Joe Medley]

philipj@opera is already working on this: https://code.google.com/p/chromium/issues/detail?id=460725

Joe Medley | Technical Writer, DevPlat | jme...@google.com | 816-678-7195

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

[Joshua Bell]

On Fri, Jun 19, 2015 at 11:25 AM, Joe Medley <jme...@google.com> wrote:

philipj@opera is already working on this: https://code.google.com/p/chromium/issues/detail?id=460725

Yes, we're in cahoots: https://codereview.chromium.org/1182233003/

[Philip Jägenstedt]

Anne, Cameron, do you have anything to say on this? There's no
technical difficulty with using DOMException for an error attribute
that I can see, but AFAIK DOMException has so far only been used as an
object to throw.

[Anne van Kesteren]

On Tue, Jun 23, 2015 at 5:23 AM, Philip Jägenstedt <phi...@opera.com> wrote:
> Anne, Cameron, do you have anything to say on this? There's no
> technical difficulty with using DOMException for an error attribute
> that I can see, but AFAIK DOMException has so far only been used as an
> object to throw.

Seems okay to me. We already have this with the error event on the
global object having a property that returns an Error object.


--
https://annevankesteren.nl/

[Philip Jägenstedt]

Do you mean the event attribute on window that returns the current Event, and undefined otherwise? The way DOMError (and MediaError) is used as an attribute is a bit different, it is an object that can be inspected when some error event is fired, but it stays in that state after the event has been fired too, and returns null if there is no error.

The API owners met to discuss this yesterday. There is a slight risk that we change specs and implementation to stop using DOMError little-by-little and in the end yet are unable to remove DOMError itself due to use of the constructor or perhaps |instanceof DOMError|, which would be quite unfortunate. I recently added some use counters that should say something about the feasibility of killing DOMError entirely. Those will be in M45, so perhaps it would be good to wait for the data from those. If it does look good, we should try killing DOMError all in a single release to reduce the amount of churn in case of failure.

[Anne van Kesteren]

On Wed, Jun 24, 2015 at 1:45 AM, Philip Jägenstedt <phi...@opera.com> wrote:
> Do you mean the event attribute on window that returns the current Event,
> and undefined otherwise?

No, I meant the error event (implements ErrorEvent).


--
https://annevankesteren.nl/

[Philip Jägenstedt]

On Wed, Jun 24, 2015 at 4:12 PM, Anne van Kesteren <ann...@annevk.nl> wrote:
>
> On Wed, Jun 24, 2015 at 1:45 AM, Philip Jägenstedt <phi...@opera.com> wrote:
> > Do you mean the event attribute on window that returns the current Event,
> > and undefined otherwise?
>
> No, I meant the error event (implements ErrorEvent).

OK, I can see ErrorEvent in our IDL files, but is there an error
attribute on some object (the global object?) that's analogous to e.g.
IDBRequest.error?

I guess what seems a bit strange about using DOMException is that
there are sometimes DOMExceptions thrown, but the ones that would be
returned by IDBError.error if this change is made wouldn't be object
that are ever thrown.

Philip

[Joshua Bell]

As noted in the original Intent, DOMExceptions are also yielded by Promise rejections from platform operations. I suppose that's basically an asynchronous exception... but then again so is IDBRequest.error (but with a less general syntax).

(I still want to hear if there are other examples or if this would be the first.)

[Anne van Kesteren]

On Wed, Jun 24, 2015 at 8:46 AM, Philip Jägenstedt <phi...@opera.com> wrote:
> OK, I can see ErrorEvent in our IDL files, but is there an error
> attribute on some object (the global object?) that's analogous to e.g.
> IDBRequest.error?

How is ErrorEvent.prototype.error not analogous? It returns an Error object...

> I guess what seems a bit strange about using DOMException is that
> there are sometimes DOMExceptions thrown, but the ones that would be
> returned by IDBError.error if this change is made wouldn't be object
> that are ever thrown.

I guess that aspect is novel.


--
https://annevankesteren.nl/

[Philip Jägenstedt]

On Wed, Jun 24, 2015 at 6:21 PM, Anne van Kesteren <ann...@annevk.nl> wrote:
>
> On Wed, Jun 24, 2015 at 8:46 AM, Philip Jägenstedt <phi...@opera.com> wrote:
> > OK, I can see ErrorEvent in our IDL files, but is there an error
> > attribute on some object (the global object?) that's analogous to e.g.
> > IDBRequest.error?
>
> How is ErrorEvent.prototype.error not analogous? It returns an Error object...

Oh, ErrorEvent.error, I really thought I was looking for some (to me
unknown) error attribute on the global object... Yeah,
ErrorEvent.error is a bit similar, it's whatever value was thrown but
not caught, which may be a DOMException.

My concern is a vague "this seems unusual" but if it seems fine to you
(and Cameron) then all is well.

I do think it would be silly if we made this switch and were still
left with DOMError, so I'll search a bit for "new DOMError" and
"instanceof DOMError" in the wild.

Philip

[Philip Jägenstedt]

I've search the 20150101 httparchive data for "DOMError", and there's a measly 22 hits:

https://gist.github.com/foolip/99798dfe9c5587ea7b8b

Most are actually for File and IndexedDB polyfills:

https://github.com/moxiecode/moxie (in documentation only)

https://github.com/axemclion/IndexedDBShim/issues/209

Given this I would expect that usage of the DOMError constructor will be extremely low, but it's probably just as well to wait.

[Joshua Bell]

The use counters have hit stable:

https://www.chromestatus.com/metrics/feature/timeline/popularity

V8DOMError_Constructor: ~0.002% (usually lower but some odd spikes)

V8DOMError_Message_AttributeGetter: 0.0001%

V8DOMError_Name_AttributeGetter: 0.009% (more heavily used on weekdays)

Again, it's unclear to me what actions to take relative to this I2S, given that a switch from DOMError to DOMException leaves the same readonly attributes in place for a consumer, and there is not yet a proposal to deprecate/remove the constructor.

I filed https://github.com/w3ctag/spec-reviews/issues/88 to get TAG feedback.

[Joshua Bell]

API Owners: given the data below, what's the feeling on shipping this? 

i.e. can this get a fresh I2S review?

Full thread w/ the I2S form: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/XAlBg66UB7c

[Philip Jägenstedt]

LGTM1

Given that DOMException also has name and message attributes, that's not a risk. The low usage of the DOMError constructor makes it seem pretty likely that it can be fully removed. If you want to deprecate the DOMError constructor, that'd be nice :)

[Rick Byers]

LGTM2

[Chris Harrelson]

LGTM3

[Joe Medley]

Can we get a dashboard entry? Developers need to change their error handling and they need to know which version. 

Joe Medley | Technical Writer, DevPlat | jme...@google.com | 816-678-7195

[Joshua Bell]

On Fri, Nov 6, 2015 at 7:59 AM, Joe Medley <jme...@google.com> wrote:

Can we get a dashboard entry? Developers need to change their error handling and they need to know which version. 

No they don't. As noted, the two object types have the same properties, so existing code that inspects the errors should continue to work. If this would impact existing code we wouldn't make the change.

(And obviously, if there is something we're missing - like someone is doing unfathomable instanceof tests - we'll revert.)

[Joe Medley]

On Fri, Nov 6, 2015 at 10:08 AM, Joshua Bell <jsb...@google.com> wrote:

(And obviously, if there is something we're missing - like someone is doing unfathomable instanceof tests - we'll revert.)

I'm worried about ANY instanceof tests. Isn't that possibility worth a heads-up?

[Joshua Bell]

On Fri, Nov 6, 2015 at 10:18 AM, Joe Medley <jme...@google.com> wrote:

On Fri, Nov 6, 2015 at 10:08 AM, Joshua Bell <jsb...@google.com> wrote:

(And obviously, if there is something we're missing - like someone is doing unfathomable instanceof tests - we'll revert.)

I'm worried about ANY instanceof tests. Isn't that possibility worth a heads-up?

Totally agree it's worth documenting: 

https://www.chromestatus.com/feature/5645171886653440

(Now I need to actually land the change...)

[Joe Medley]

Thank you.

Joe Medley | Technical Writer, DevPlat | jme...@google.com | 816-678-7195