BinaryStream.ReadyBytes is difficult to use in streams because it throws

einhugur

BinaryStream.ReadyBytes is difficult to use because it throws exception when reading past end of stream..

Usual behavior when reading streams would be to let it return fewer bytes than what the requested amount was.

When getting exception at this point then the only way to use this for buffered streaming is to manually try to keep track of the sizes and then request less for the last buffer which is just pita and error prone.

Garry

I agree. Having to calculate the size of the final buffer makes ordinary chunked reading unnecessarily awkward.

My proposal is to change ReadBytes(byteCount) so it returns fewer bytes when it reaches EOF. For example, requesting 4,096 bytes when only 100 remain would return a MemoryBlock containing those 100 bytes. Reading again at EOF would return an empty MemoryBlock. ReadBytesAsync would behave the same way.

I will also add two methods for cases where the complete requested amount is required:

ReadBytesExactly(byteCount)
ReadBytesExactlyAsync(byteCount)

These would throw an IOException if EOF prevents them from reading the full amount. They would be useful when reading a fixed-size header or record where missing bytes indicate truncated data.

Primitive reads such as ReadInt32 would continue to throw when there are insufficient bytes. Closed streams and actual I/O errors would also continue to raise exceptions.

This changes the existing EOF behaviour, so code that currently relies on ReadBytes throwing for incomplete data would need to use ReadBytesExactly instead. I’ve logged the proposal, including tests for both versions and documentation explaining the change.

Garry

This has been implemented in the next release.