stream: throw instead of destroy?

[rexagod]

I've come across multiple instances (in http2, for example) where due to a condition not being fulfilled, an error was thrown rather than destroying the stream itself (which would emit an error event and hence would be easier to work with).

I wanted to know if there's any reason behind not destroying the stream, or if this needs to be fixed?

[ronag]

I wanted to know if there's any reason behind not destroying the stream, or if this needs to be fixed?

This has been discussed a few times in the past. Most recently in #31818.

Some refs:

#31831 (comment)
#31831
#31818

[ronag]

It's a case of logic (throw) vs runtime (destroy) errors.

[rexagod]

Thank you for the quick response, ronag!

Quoting @mscdex from #31818 (review),

Not throwing errors goes against behavior found throughout node.

Throwing should be used when there is a user error of one kind or another that can be immediately detected: when the stream has already ended (something that the user could check easily first), if an argument of the wrong type is passed, etc.

I'll work on a PR soon to ensure that this logic is implemented in streams (and HTTP[s]\1\2).

[ronag]

I'll work on a PR soon to ensure that this logic is implemented in streams (and HTTP[s]\1\2).

Please note that this is not currently the consensus. Throwing is not always preferred. Please read the rest of the discussion.

[BridgeAR]

I am closing this as there does not seem anything in particular actionable.