Closed RoySalisbury closed 6 years ago
Hi, yes I'm aware of this and I made a conscious decision to do so. The comments in code are:
/// <returns>
/// The total number of bytes read into the buffer. This can be less than
/// the number of bytes requested if that many bytes are not currently
/// available, or zero (0) if the end of the stream has been reached.
/// </returns>
Why did I do this? SerialPortStream from MS is an exception that most streams do really return 0 on end of stream or timeout. They typically only throw the exception on write.
If a user expects a stream, I wanted to alleviate them a little of having to know if this is a serial port or not, so I return zero more consistent with all other stream.
It is a minor point that developers need to consider.
Just found that calling .Read(..) that if no data is available to be read within the ReadTimeout period, that a "TimeoutException" does not occur.
That is the behaviour in the original .NET SerialPort. Was easy to work with (just check for 0 bytes read).
I honestly like the non-exception way better, but if you're going for backwards compatibility, it will be a breaking change from SerialPort.