search

whatwg / compression

Compression Standard
https://compression.spec.whatwg.org/
Other
85 stars 21 forks source link

Why TypeError instead of DOMException DataError for decompression failure? #51

Open saschanaz opened 1 year ago

saschanaz commented 1 year ago

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

  1. 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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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.