Creating your own errors

Anne van Kesteren annevk at annevk.nl
Tue Aug 6 09:27:48 PDT 2013


Just to relay here what I discussed with Allen in the off-periods of
the last TC39 meeting.

On Wed, Jul 17, 2013 at 12:30 AM, Jonas Sicking <jonas at sicking.cc> wrote:
> x.name == "HierarchyRequestError"
> This should test true. This should be uncontroversial enough that I
> don't think it matters how much dependency there is, right? Obviously
> the exact value varies with the exception type.

Given that for every JavaScript exception x.name is the name of the
object, violating that is actually breaking a pattern. x.name should
be DOMException. We could have x.subname that would be something more
specific.


> I think we have the following constraints for properties that contain
> error information in APIs that currently use DOMError
> (IDBTransaction.error in the IndexedDB spec for example).
>
> x.name = "AbortError"
> This should be uncontroversial enough that I don't think it matters
> how much dependency there is, right?

This has the same problem. It might be worse here.


> My recommendation would be to
> * Get rid of DOMError and use DOMException in its place

Agreed.


> * Add new subclasses for each exception type. I.e. exceptions with
> .name == HierarchyRequestError should also test true for "instanceof
> HierarchyRequestError"

Allen and I both agreed this would be overkill. Using .subname or some
such should be sufficient.


> * Keep specifying that DOMException is a subclass of Error. This is
> already the case, but I wanted to make it clear that this shouldn't
> change.

Agreed.


-- 
http://annevankesteren.nl/


More information about the es-discuss mailing list