Jonas Sicking (2013-07-11T03:31:21.000Z)
On Jul 10, 2013 3:49 PM, "Erik Arvidsson" <erik.arvidsson at gmail.com> wrote:
>
> Jonas, DOM never throws DOMError. DOMErrors are used for other error
> mechanisms, such as callbacks. [1]

Indeed. But this is one of the things I'm trying to fix. It seems very
silly that the DOM defines two classes of error objects. Neither of which
are following the patterns used by ES.

/ Jonas

>
> The DOM spec does however throw DOMException objects [2]. These are
> instanceof Error (see WebIDL [3])
>
> var ex;
> try {
>   document.appendChild(document);
> } catch (e) {
>   ex = e;
> }
> assert(ex instanceof Error);
> assert(ex.contructor === DOMException);
> assert(ex.name === 'HierarchyRequestError');
>
> In Blink DOMException also have a stack property
> assert(stack in ex);
>
> [1] http://dom.spec.whatwg.org/#interface-domerror
> [2] http://dom.spec.whatwg.org/#exception-domexception
> [3]
http://dev.w3.org/2006/webapi/WebIDL/#es-exception-interface-prototype-object
>
> On Wed, Jul 10, 2013 at 3:02 PM, Jonas Sicking <jonas at sicking.cc> wrote:
> > On Wed, Jul 10, 2013 at 12:52 PM, Domenic Denicola
> > <domenic at domenicdenicola.com> wrote:
> >> Woah, François, that seems pretty overcomplicated; why not replace
everything inside the constructor with `this.message = message`? It has the
same effect in the browsers I've seen. (Also don't forget
`SomeError.prototype.constructor = SomeError`.)
> >>
> >> Anyway, to Jonas's point: I think `DOMError` is actually pretty OK.
One thing I noticed is that the ES5 spec (and presumably ES6, although I
haven't checked) is careful to never throw simple `Error` objects, but
instead `TypeError`s or `RangeError`s or so on. I infer that they are
leaving bare `Error` for user cases. I think "the platform" should
generally follow this lead; that is, the DOM should leave bare `Error`s to
the user, and throw `DOMError`s or `TypeError`s or `RangeError`s for its
own errors.
> >>
> >> To answer your more general question, authors are strongly discouraged
from ever throwing anything that is not `instanceof Error`, see e.g.
Guillermo Rauch's [A String is not an Error](
http://www.devthought.com/2011/12/22/a-string-is-not-an-error/). Also, the
`name` property is generally the same across all instances of a particular
error type, i.e.
> >>
> >> ```js
> >> errInstance.name === errInstance.constructor.name ===
errInstance.constructor.prototype.name ===
Object.getPrototypeOf(errInstance).name
> >> ```
> >>
> >> (You can verify this for all the built-in ES5 errors.) Usually a
`code` property is used for more specific information, from what I've seen.
But yes, that has to be added manually with a bit of awkwardness, i.e.
> >>
> >> ```js
> >> const e = new DOMError("The message");
> >> e.code = "TimeoutError";
> >> throw e;
> >> ```
> >
> > Note that
> >
> > (new DOMError) instanceof Error;
> >
> > returns false. So the DOM does do the "strongly discouraged" thing. Is
> > this ok or bad?
> >
> > Also, the DOM does not create a new class for each different value of
.name.
> >
> > I.e. you can get a DOMError whose .name is "NetworkError" or
> > "AbortError". DOMError even has a constructor which allows setting
> > .name to anything: new DOMError(name, message);
> >
> > In fact, there are no defined situations where the DOM creates
> > DOMError objects whose .name is "DOMError".
> >
> > Again, is this ok or is it bad practice?
> >
> > / Jonas
> > _______________________________________________
> > es-discuss mailing list
> > es-discuss at mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
>
>
>
> --
> erik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130710/8309b74d/attachment.html>
forbes at lindesay.co.uk (2013-07-12T03:07:34.999Z)
Erik Arvidsson wrote:
> DOMErrors are used for other error mechanisms, such as callbacks. [1]

Indeed. But this is one of the things I'm trying to fix. It seems very
silly that the DOM defines two classes of error objects. Neither of which
are following the patterns used by ES.