Error objects in W3C APIs
domenic at domenicdenicola.com
Wed Feb 5 22:50:52 PST 2014
From: Jonas Sicking [mailto:jonas at sicking.cc]
> I agree. Creating hierarchies of error "types" seems fragile to me.
> A better approach seems like having a short list of flat error types. In cases where it might be useful to have a more specific error type, instead include additional information on the error. So for example, rather than having a NetworkResourceNotFound error, use NetworkError but add a property which indicate what type of network failure. Not sure if that was what you were proposing with the "proximate cause"?
Yeah, basically. Although I question the utility of the types at all. As discussed in [the earlier thread about an InvalidOperationError], in practice bucketing errors into the short list of types isn't particularly helpful, I think.
> (... a bunch of stuff I agree with regarding DOM errors.)
> I'm not sure that there's a difference between these two. Or at least I don't think there's a difference between the stuff that the DOM puts in .name, and that ES puts in the classname. They express the same thing just in different ways.
Yeah. And the divergence is unfortunate, although not that big a deal, since it's kind of minor and in practice nobody really tries to use either the classname or name to distinguish, from what I see.
> I don't think we should specify the exact string that goes into these messages. It's good if implementations are free to add additional details if they see developers struggling with something.
> But we could definitely do with more recommendations for implementations about what information to include here.
That would be cool in my opinion. The removal at  saddened me a bit. I wonder what other spec writers' perspectives are, given that nobody does so. Are we all just following accepted practice, but would be happy to switch? Or are there people that believe such guidance would be a bad thing?
> I think a proposed solution would help clarify.
> For your Stream example above I would propose using an InvalidStateError but give it a couple of properties so that code could understand what went wrong. Maybe a property which contains "BaseWritableStream.write" to indicate that that was the function that failed, and a second property which contains "closing" or "closed" to indicate which wrong state was hit. This is definitely a very unpolished proposal, but might illustrate something that could work.
Yeah, basically. My initial thought was some kind of identifier. E.g.
var closingError = new TypeError("nice human message");
closingError.cause = "wrote_while_closing";
var closedError = new TypeError("another nice human message");
closedError.cause = "wrote_while_closed";
(The underscores could actually be replaced with spaces, but then it feels less identifier-ey. Kind of a strange thing when you think about it.)
The idea would be that you try to maintain a globally-unique list of causes, so that people can match on exactly the cause they care about. Unlike `DOMException` names, you don't maintain a global list so that people can consult it and find a cause that matches; you maintain that global list so that people can consult it and *not* accidentally re-use a cause. It has all the normal fragility properties of a global registry, of course. Hmm.
Your idea of indicating which method caused the failure is a very interesting one as well. I wonder if it is related to the error stack trace in a universal fashion. Certainly for user-space errors it is not, since if you refactor to call a helper function outside of your public API that throws an error, you'd want the "causer" to be the public API method, not the helper function. But it might be for web platform APIs, since in practice they hide their helper functions using self-hosted or C++ tricks.
I've asked some Node people what info they think is most useful, since apparently they're starting to realize that they've built up some de-facto standards in Node core around this stuff and are thinking of making those more explicit and universal. It'll be interesting to see what they come up with. (Trevor Norris, if you're listening, feel free to chime in!)
More information about the es-discuss