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

> From: Allen Wirfs-Brock <allen at wirfs-brock.com>
> 
>> 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.
> 
> This seems like a stretch :P. Are there existing instances in the ES spec of this kind of use? I guess maybe trying to write to a non-writable property in strict mode and the like.

Sure, all over the place.  For example, trying to apply a built-in constructor to an object that doesn't have the expected set of internal slots.

> 
>> In practice, where would throwing OperationError instead of TypeError actually make any difference.  How would you handle one differently from the other?
> 
> In practice it makes almost no difference, just like all other ECMAScript error type discrimination. It just seems that when a user sees `TypeError` in a stack trace, they expect to find some kind of argument validation problem.
> 
> (Maybe once we get pattern-matching `catch` clauses it would matter more. E.g. people could purposefully try to catch `OperationError`s from such operations, and handle them differently, leaving `TypeError`s etc. to bubble outward and hit a top-level exception handler as "truly unexpected." But that's a ways off.)
> 
> ---
> 
> Sounds like `TypeError` is probably the way to go, even if it feels a bit off.

We work with the tools that are available...

>

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

> Are there existing instances in the ES spec of this kind of use? I guess maybe trying to write to a non-writable property in strict mode and the like.

Sure, all over the place.  For example, trying to apply a built-in constructor to an object that doesn't have the expected set of internal slots.

> Sounds like `TypeError` is probably the way to go, even if it feels a bit off.

We work with the tools that are available...