Exception type for "invalid operations"?
jsbell at chromium.org
Thu Jan 30 10:32:40 PST 2014
On Thu, Jan 30, 2014 at 8:25 AM, Domenic Denicola <
domenic at domenicdenicola.com> wrote:
> I'm trying to design the [whatwg/streams spec] in the style of
> ECMAScript primitives, since I find that style more precise and idiomatic,
> and potentially in the future streams could become a language-level
> feature. Basically, I want to get ahead of the situation
> `TextEncoder`/`TextDecoder` find themselves in, as per [recent
Even following the link, I'm unsure if you're referring to the use of
DOMException with name "EncodingError", or something else in that thread.
(If something else, can you ping me directly?)
> One thing I'm stuck on is what exception type to use for invalid
> operations. For example, trying to read from or write to a closed stream.
> None of the ECMAScript standard types---`EvalError`, `RangeError`,
> `ReferenceError`, `SyntaxError`, `TypeError`, and `URIError`---seem to
> match. Do I just give up and use `TypeError`, which seems to be the
> catch-all in most situations?
Distinct DOMException types used to be defined with a numeric enum. That's
changed to distinct strings (hence the DOMException w/ name
"EncodingError", for example), and specs can add new types without
requiring additions to an enum tracked in the DOM spec.
Even with the ability to have feature-specific names error names, the
specific types don't communicate enough detail for developers to know
what's going on (e.g. "InvalidStateError" - uh, why?). In Chromium we're
trying to update the messages to indicate e.g. the method being called
("Failed to execute 'put' on 'IDBObjectStore': ...") in addition to the
specific details ("The transaction is not active."). But at least with the
flexibility for a feature to define a specific error, you can point to the
line in the spec that explains why it's being thrown. Which argues for
allowing feature-specific error types and against an explosion of types
that need defining in ES where strings would be sufficient.
So... can we simply use Error() with documented |name| (for code to reason
about) and detailed |message| (for developers to log/debug) ?
> Or would it make sense to open ourselves up beyond the existing set, and
> define some kind of `InvalidOperationError`? The idea being that, *if*
> streams were to become an ECMAScript primitive, so would
> `InvalidOperationError`. (*If*, not when! Please don't read too much
> presumptuousness into my API design predilections.)
> Other languages seem to have something similar: [.NET's
> `InvalidOperationException`] and [Java's `IllegalStateException`]
> come to mind. But of course they have much deeper exception hierarchies,
> which I don't think we want to emulate.
> : https://github.com/whatwg/streams
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss