Signaling TypeErrors

[rtoy]

This is a continuation of #1166 which was about TypeError in general but has been changed to be just about decodeAudioData.

As mentioned in #1166 (comment), there are other cases where we specify a TypeError.

I think we need to consider this carefully (and also any other specified error types that we signal). I think it's important to get this right the first time. Changing it in v.next will break all kinds of code if any one depending on the error type.

[rtoy]

Here is a list of places where we say TypeError is thrown but aren't really TypeError's at the binding layer. Typically we say this for floats that aren't positive. Instead of TypeError, maybe NotSupportedError or InvalidStateError?

• cancelAndHoldAtTime
• cancelScheduledValueAtTime
• exponentialRampToValueAtTime
• linearRampToValueAtTime
• setTargetAtTime
• setValueAtTime
• setValueCurveAtTime
• start
• AudioBufferSource start
• stop

[rtoy]

Maybe RangeError would be the best: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/RangeError

[rtoy]

Or maybe not RangeError. In Chrome, RangeError is implemented in the binding layer. I'll have to ask around about this.

[rtoy]

Talked to @domenic and others about this. RangeError seems fine. If it can't be used in Chrome, that's a Chrome bug.

For reference: https://heycam.github.io/webidl/#idl-DOMException-error-names, so we should avoid the deprecated terms. (@domenic also mentioned that IndexSizeError should be deprecated as well in favor of RangeError. Not proposing we change the existing uses of IndexSizeError.)

[padenot]

That's good. I like RangeError.