Why TypeError instead of DOMException DataError for decompression failure?

[saschanaz]

trafficstars

https://wicg.github.io/compression/#decompress-flush-and-enqueue

2. If the end of the compressed input has not been reached, then throw a TypeError.

Not that it matters too much, but not sure TypeError makes much sense there.

[ricea]

I have a preference for simple exceptions, but I don't have a good justification for it.

I think the compatibility risk for changing this would probably be minimal, but I don't have a way of measuring it.

@domenic Can I ask you for an opinion?

[domenic]

I think the relevant question is whether there are use cases for discriminating the error types coming out of the stream. If so, using separate exception types is worthwhile. If not, sticking with the generic, default TypeError makes sense.

[ricea]

For someone trying to use DecompressionStream for the first time, it might be useful to distinguish between TypeError meaning "you gave me something that wasn't a BufferSource" and DataError meaning "the input was not a valid compressed stream".

On the other hand, TextDecoderStream uses TypeError for bad input, and maybe consistency is more important here.