Errors receiving should not be fatal?

Hi,

Occassionally using the client I receive a header that triggers the following exception:
private static WebSocketFrame processHeader (byte[] header)
{
if (header.Length != 2)
throw new WebSocketException ("The header of a frame cannot be read from the stream.");

This raises a fatal error which doesn't seem handleable by my encapsulating code because the method that initialises the client has finished and the error is caught before the OnMessage event is raised.

It also seems that fatal errors do not raise the OnError event.

This leaves me in the situation that a potenetially recoverable error is not handled and halts my datafeed in my windows service.

I have altered the code above processHeader() to treat this exception as an error rather than fatal, and in the event handler for OnError I simply ditch the object and reinitialise. For me this works great but I'm not always keen on modifying libraries and this seems like it might be something to consider for an architectural change?

Unless of course I'm doing something wrong and ther is a proper way to handle this?

Thanks for the hard work on the library, it sped up my dev time no end.

Cheers,
Ashley

Start by tracing processHeader and the client’s OnError and OnMessage event flow described in the issue, including where client initialization returns. Reproduce the short-header case and define done as making recoverable receive errors observable through the documented handling path without terminating the data feed.