IndexOutOfRangeException when a stream is a multiple of the buffer size

Question

I don't have a lot of experience with streams and buffers, but I'm having to do it for a project, and I'm stuck on an exception being thrown when the stream I'm reading is a multiple of the buffer size I've chosen. Let me show you:

My code starts by reading bufferSize (100, let's say) bytes from the stream:

numberOfBytesRead = DataReader.GetBytes(0, index, output, 0, bufferSize);

Then, I loop through a while loop:

while (numberOfBytesRead == bufferSize)
{
     BufferWriter.Write(output);
     BufferWriter.Flush();
     index += bufferSize;
     numberOfBytesRead = DataReader.GetBytes(0, index, output, 0, bufferSize);
}

... and, once we get to a non-bufferSize read, we know we've hit the end of the stream and can move on.

But if the bufferSize is 100, and the stream is 200, we'll read positions 0-99, 100-199, and then the attempt to read 200-299 errors out. I'd like it if it returned 0, but it throws an error. What I'm doing to handle that is, well, a try-catch:

catch (System.IndexOutOfRangeException)
    numberOfBytesRead = 0;

...which ends the loop, and successfully finishes the thing, but we all know I don't want to control code flow with error handling.

Is there a better (more standard?) way to handle stream reading when the stream length is unknown? This seems like a small wrinkle in a fairly reasonable strategy for reading streams, but I just don't know if I've got it wrong or what.

The specifics of this (which I've cleaned up a little bit for posting) are a MySqlDataReader hitting a LARGEBLOB column. It's working whenever the buffer is larger than the number of returned bytes, or when the number of returned bytes is not a multiple of bufferSize. Because we don't, in that case, throw an IndexOutOfRangeException.

Answer 1

You don't have to be in the dark about the blob's size:

long blobSize = dr.GetBytes(0, 0, null, 0, 0);

...and then, before you do your read, you can just check to see that index is less than blobSize. If it isn't, you know you've capped it, and have read everything there is to read.

Answer 2

Not sure if there is a real question here. But the code as posted is fundamentally wrong. A stream is not obligated to return the requested number of bytes. It can return less, and often does. Only when it returns 0 do you know for a fact that you've reached the end of the stream.

This allows a stream to optimize its internal buffer usage and improves overlapped I/O throughput. NetworkStream is a good example.