Make read consistent about byte-stream HOT 9 CLOSED

Shouldn't trying to read a closed stream hint you that you attempted to read closed stream?

from byte-stream.

@ekinhbayar only if you want to read a fixed amount of bytes (where you want a guarantee that the returned string is exactly that long) [as opposed to up to].
In any other case, a string of size 0 (or null for instance) is not problematic. It's even desirable, as you expect that streams are going to end sometime.

from byte-stream.

@bwoebi I think @ekinhbayar's point is reading repeatedly from an already closed stream.

@ekinhbayar: Yes, that's probably always a programming error, but it makes implementing some things more complex. It's a trade-off for easier to implement streams.

from byte-stream.

I disagree.

There might be e.g. multiple optional parts at stream end, so, when you try to do multiple calls to read until EOL, the optional parts will just end up with null, but that's totally fine.
If it were throwing an exception, that'd need unnecessary extra handling complexity in user side.

from byte-stream.

There might be e.g. multiple optional parts at stream end, so, when you try to do multiple calls to read until EOL, the optional parts will just end up with null, but that's totally fine.

I do not understand, could you illustrate with an example?

from byte-stream.

I can see read returning either Promise or null being desirable. I was thinking in case when you try to read from the stream again, maybe multiple times, after it is closed. +1 for an example to see that point clearly, but I understand the preference of null instead of an exception.

from byte-stream.

@ekinhbayar See 23f5ba9 for an example with an exception instead of null after the first null.

The return type is always Promise, not Promise|null, but the promise resolves to string|null.

from byte-stream.

@kelunik seems I misinterpreted, I see how it is now.

from byte-stream.

I think this task has been completed. Everything else is a bug.

from byte-stream.