Recoverable error from failed parameter validation?

[saschanaz]

There have been some questions from WebTransport and File System where their algorithms have validation steps:

• WebTransport: A pull algorithm throws RangeError if the BYOB view is smaller than the chunk (https://w3c.github.io/webtransport/#datagram-duplex-stream-procedures)
• File System: A write algorithm throws TypeError if there's a missing field in the chunk (https://fs.spec.whatwg.org/#write-a-chunk)

Both of them want to tell the caller that the parameter is invalid, but it cannot be recovered without getting a new stream as the validation error stops the existing stream. There's no good try-catch for those streams.

Maybe File System can do the validation early in its FileSystemWritableFileStream.write() without errorring the stream, but do we want other specs to get their own methods for this? Perhaps also related to #1072.

cc @jesup @jan-ivar @jjjalkanen

[ricea]

The lack of "soft" errors in WritableStream was an intentional design decision to avoid situations where one of a number of queued writes fails and leaves the output corrupted due to the missing chunk.

In File System, writing a chunk with a missing field is clearly an authoring error and I think making it recoverable would just encourage authors to not fix their bugs.

The case of an "incorrect buffer size" with WebTransport datagrams is a weird one caused by us ascribing semantics to buffer boundaries in byte streams which was not intended by the streams specification. It can easily be averted by always using buffers of size 65536, so I'm not too worried about our unfriendly behaviour of erroring the whole stream.

I think the absence of a hard/soft error distinction makes the standard more predictable and easy-to-use, even if in some cases richer error signalling would be attractive.

[saschanaz]

where one of a number of queued writes fails and leaves the output corrupted due to the missing chunk.

This is an interesting point. Can we do the validation early before queuing? (i.e. have a separate "validation step"?)

[MattiasBuelens]

Can we do the validation early before queuing? (i.e. have a separate "validation step"?)

The problem is that the WritableStream may be part of a long pipe chain. If the writable throws a "soft" error, then there's nowhere for that error to go.

[saschanaz]

Can we do the validation early before queuing? (i.e. have a separate "validation step"?)

The problem is that the WritableStream may be part of a long pipe chain. If the writable throws a "soft" error, then there's nowhere for that error to go.

Exactly, and that's why I mentioned FileSystemWritableFileStream.write(), which theoretically can be made to run additional steps separate from the write algorithm and thus do not affect piping (i.e. let it fail hard as it does now).