#88: Feedback on DOMError -> DOMException in Indexed DB

Visit on Github.

Opened Oct 15, 2015

Based on the general guidance "DOMError is dead, use DOMException instead", in the Indexed DB "Second Edition" we've basically done a s/DOMError/DOMException/g find/replace. This should not impact most scripts, since the attributes present on DOMError (name, message) are present in DOMException. The only impact would be scripts that do instanceof tests on the type of the object.

There's been feedback that this might seem a bit odd, as it's the first place that DOMExceptions surface as attribute values rather than as thrown exceptions/promise rejections. Also, they aren't subclassed as e.g. IDBError or anything fancy like that.

TAG, what say you?

Discussions

Comment by @domenic Oct 15, 2015 (See Github)

This goes back to some long-ago discussions... It was never a good idea to have two separate error types in the platform. There's no reason to create two types just so that you can use them in different circumstances.

Comment by @foolip Oct 16, 2015 (See Github)

I was the one (or at least one of those) who hesitated because this is the first case I know where DOMException is used as an attribute. I've now gotten used to the idea and think that if we can successfully remove DOMError (uncertain) then it'll be fine to use DOMException for things that aren't actually thrown.

Comment by @travisleithead Jan 6, 2016 (See Github)

Discussed in TAG teleconference 6 Jan 2016. TAG doesn't see any issues with using DOMException in this way. We didn't have @slightlyoff on the call, so we'd like him to have a chance to weigh-in as well before closing. Alex, any concerns?

Comment by @slightlyoff Jan 14, 2016 (See Github)

Change looks good. Thanks for making it!

It raises a good point for the TAG that we should be encouraging DOMException and should include that in our advice to spec authors. @dbaron is filing an issue on us for that.