On Jan 30, 2014, at 8:25 AM, Domenic Denicola wrote:

> I'm trying to design the [whatwg/streams spec][1] 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 discussions][2].
> 
> 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?
> 
> 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`][3] and [Java's `IllegalStateException`][4] come to mind. But of course they have much deeper exception hierarchies, which I don't think we want to emulate.

So far we've avoiding adding any new built-in exceptions.  Perhaps, we could add another but I think it would take some time to build consensus around that.

In practice new library functions in ES6 restrict themselves to using either TypeError or RangeError with TypeError being by far the most common.  Range error is used when a parameter or other value is (likely) of the correct primitive type (number, string, etc.) but the specific value is not contextually valid.  Pretty much everything else is treated as a TypeError.  Note that in this context we interpret "Type"  more like "kind" than corresponding the ECMAScript types. You can think about this usage of TypeError as "the wrong kind of thing was directly or indirectly passed to the function".  If you invert things you can think of "invalid operation" as trying to apply a valid operation upon the "wrong kind of object" so TypeError is a plausible.

In practice, where would throwing OperationError instead of TypeError actually make any difference.  How would you handle one differently from the other?

Allen
> 
> [1]: https://github.com/whatwg/streams
> [2]: http://esdiscuss.org/topic/need-a-champion-stringview-strawman#content-17
> [3]: http://msdn.microsoft.com/en-us/library/system.invalidoperationexception%28v=vs.110%29.aspx
> [4]: http://docs.oracle.com/javase/7/docs/api/java/lang/IllegalStateException.html
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>

So far we've avoiding adding any new built-in exceptions.  Perhaps, we could add another but I think it would take some time to build consensus around that.

In practice new library functions in ES6 restrict themselves to using either TypeError or RangeError with TypeError being by far the most common.  Range error is used when a parameter or other value is (likely) of the correct primitive type (number, string, etc.) but the specific value is not contextually valid.  Pretty much everything else is treated as a TypeError.  Note that in this context we interpret "Type"  more like "kind" than corresponding the ECMAScript types. You can think about this usage of TypeError as "the wrong kind of thing was directly or indirectly passed to the function".  If you invert things you can think of "invalid operation" as trying to apply a valid operation upon the "wrong kind of object" so TypeError is a plausible.

In practice, where would throwing OperationError instead of TypeError actually make any difference.  How would you handle one differently from the other?