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.
object, violating that is actually breaking a pattern. x.name should
be DOMException. We could have x.subname that would be something more
> 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
> * Add new subclasses for each exception type. I.e. exceptions with
> .name == HierarchyRequestError should also test true for "instanceof
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
More information about the es-discuss