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

102 views
Skip to first unread message

Joshua Bell

unread,
Jun 19, 2015, 1:33:51 PM6/19/15
to blink-dev

Contact emails

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


Spec

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

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

unread,
Jun 19, 2015, 2:25:47 PM6/19/15
to Joshua Bell, blink-dev
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

unread,
Jun 19, 2015, 2:31:26 PM6/19/15
to Joe Medley, blink-dev
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


Philip Jägenstedt

unread,
Jun 23, 2015, 8:23:21 AM6/23/15
to Joshua Bell, Anne van Kesteren, Cameron McCormack, blink-dev
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

unread,
Jun 23, 2015, 12:08:06 PM6/23/15
to Philip Jägenstedt, Joshua Bell, Cameron McCormack, blink-dev
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

unread,
Jun 24, 2015, 4:45:27 AM6/24/15
to Anne van Kesteren, Joshua Bell, Cameron McCormack, blink-dev
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

unread,
Jun 24, 2015, 10:13:02 AM6/24/15
to Philip Jägenstedt, Joshua Bell, Cameron McCormack, blink-dev
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

unread,
Jun 24, 2015, 11:47:02 AM6/24/15
to Anne van Kesteren, Joshua Bell, Cameron McCormack, blink-dev
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

unread,
Jun 24, 2015, 12:11:45 PM6/24/15
to Philip Jägenstedt, Anne van Kesteren, Cameron McCormack, blink-dev
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

unread,
Jun 24, 2015, 12:21:56 PM6/24/15
to Philip Jägenstedt, Joshua Bell, Cameron McCormack, blink-dev
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

unread,
Jun 24, 2015, 3:02:40 PM6/24/15
to Anne van Kesteren, Joshua Bell, Cameron McCormack, blink-dev
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

unread,
Jun 25, 2015, 4:55:29 AM6/25/15
to Anne van Kesteren, Joshua Bell, Cameron McCormack, blink-dev
I've search the 20150101 httparchive data for "DOMError", and there's a measly 22 hits:

Most are actually for File and IndexedDB polyfills:
https://github.com/moxiecode/moxie (in documentation only)

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

unread,
Oct 15, 2015, 5:31:05 PM10/15/15
to Philip Jägenstedt, Anne van Kesteren, Cameron McCormack, blink-dev
The use counters have hit stable:

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.




Joshua Bell

unread,
Nov 5, 2015, 2:26:15 PM11/5/15
to Philip Jägenstedt, Anne van Kesteren, Cameron McCormack, blink-dev
API Owners: given the data below, what's the feeling on shipping this? 

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

Philip Jägenstedt

unread,
Nov 5, 2015, 2:47:55 PM11/5/15
to Joshua Bell, Anne van Kesteren, Cameron McCormack, blink-dev
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

unread,
Nov 5, 2015, 2:54:14 PM11/5/15
to Philip Jägenstedt, Joshua Bell, Anne van Kesteren, Cameron McCormack, blink-dev
LGTM2

Chris Harrelson

unread,
Nov 5, 2015, 5:13:45 PM11/5/15
to Rick Byers, Philip Jägenstedt, Joshua Bell, Anne van Kesteren, Cameron McCormack, blink-dev
LGTM3

Joe Medley

unread,
Nov 6, 2015, 10:59:46 AM11/6/15
to Chris Harrelson, Rick Byers, Philip Jägenstedt, Joshua Bell, Anne van Kesteren, Cameron McCormack, blink-dev
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

unread,
Nov 6, 2015, 1:08:50 PM11/6/15
to Joe Medley, Chris Harrelson, Rick Byers, Philip Jägenstedt, Anne van Kesteren, Cameron McCormack, blink-dev
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

unread,
Nov 6, 2015, 1:18:52 PM11/6/15
to Joshua Bell, Chris Harrelson, Rick Byers, Philip Jägenstedt, Anne van Kesteren, Cameron McCormack, blink-dev

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

unread,
Nov 6, 2015, 1:32:15 PM11/6/15
to Joe Medley, Chris Harrelson, Rick Byers, Philip Jägenstedt, Anne van Kesteren, Cameron McCormack, blink-dev
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: 


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

Joe Medley

unread,
Nov 6, 2015, 1:34:32 PM11/6/15
to Joshua Bell, Chris Harrelson, Rick Byers, Philip Jägenstedt, Anne van Kesteren, Cameron McCormack, blink-dev
Thank you.

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

Reply all
Reply to author
Forward
0 new messages