Deferred Readable stream error events

[kanongil]

In the current streams2 Readable implementation "error" emits are immediately forwarded to the listeners. Since it is implied that stream "error" emits are fatal, any internally buffered data will essentially be discarded.

This can cause less than optimal behavior when the errors are temporal in nature, such as disconnection errors. In these cases the stream consumers can be interested in all the possible data to better recover from the error.

I'm sure this could somehow, if awkwardly, be worked around client-side but the more obvious solution is to add a way to signal temporal errors. This signal can internally end the stream and replace the final "end" emit with an "error" emit. Perhaps exposed as .push(new Error('disconnected'))?

Any thoughts? Would this be an acceptable API extension?

/cc @isaacs

[chrisdickinson]

The stream error behavior is unlikely to change this drastically. One benefit of the current behavior is that when errors occur, there is often enough context left in _readableState.buffer (or _writableState.buffer) to be able to determine when the error occurred. You may be interested in this PR, which specs out a way to "handle" errors without unpiping -- though, of note, it hasn't been accepted and is more of a starting point for conversation than a final API.

[kanongil]

@chrisdickinson My suggestion was not towards the generic streaming interface but rather as an additional api that Readable implementors can signal temporal errors through, allowing all data to be consumed before signalling the error. Outwardly no changes will be visible until Readable implementors actually make use of this new api.

The reason I brought it up, is that it is very impractical to implement this behavior as it is, requiring extensive knowledge of Readable internals.