Exception inside SocketClient.ProcessReceive is not handled about iqfeed.csharpapiclient HOT 12 CLOSED

As I said it was probably IqFeed who sent the bad data. I do have requested tickers in my logs, but they receive good replies when being requested at the moment. I think it was something going on IqFeed side exactly at that moment (Jan 27, 5:35 PM EST), because the service continue to crash after automatic restart several times.

Nevertheless we must be somehow prepared for such situation (bad data from the vendor) and have an ability to handle it gracefuly. I am going to make a fix in a day or so, can file it as a PR.

from iqfeed.csharpapiclient.

@gribunin do you remember the ticker? Are you able to reproduce?

from iqfeed.csharpapiclient.

@gribunin absolutely this is bad data from the vendor. I dont want to change the types as already mention in another discussion. What are you suggesting ? Using TryParse instead like we do for streaming data? If it doesnt parse properly we need to be aware in other to drop the bad data.

from iqfeed.csharpapiclient.

I am suggesting to have a global try/catch in SocketClient.ProcessReceive, also add an event handler OnException to SocketClient, pass the caught exception object to this handler. Then subscribe to this event handler (OnException) in GetMessagesAsync and rethrow the exception passed to this handler there.

This way, the calls to lookupClient.Historical.GetHistoryTickDatapointsAsync and other API methods wrapped to try/catch will catch these exceptions.

from iqfeed.csharpapiclient.

I am suggesting to have a global try/catch in SocketClient.ProcessReceive, also add an event handler OnException to SocketClient, pass the caught exception object to this handler. Then subscribe to this event handler (OnException) in GetMessagesAsync and rethrow the exception passed to this handler there.

This way, the calls to lookupClient.Historical.GetHistoryTickDatapointsAsync and other API methods wrapped to try/catch will catch these exceptions.

not sure I like this solution. Maybe converting all Parse to TryParse makes more sense to me.

from iqfeed.csharpapiclient.

If convert Parse to TryParse what is going to be done when TryParse fails? The calling method will throw an exception?

from iqfeed.csharpapiclient.

If convert Parse to TryParse what is going to be done when TryParse fails? The calling method will throw an exception?

not at all.... TryParse doesnt throw.

from iqfeed.csharpapiclient.

@gribunin please., lets start with this first. create a PR converting double.Parse DateTime.ParseExact int.Parse
like we do in UpdateSummaryMessage

from iqfeed.csharpapiclient.

I see what you mean. Do you think its a correct approach to swallow bad data from iqfeed and just return zeros in the fields which couldnt be parsed? How will a client know that its not a correct TickMessage and that actually bad data has been received?

from iqfeed.csharpapiclient.

Added a pull request (#97) with my idea to catch exceptions and marshal them to the caller context. This way the caller can catch the situation when IqFeed returned bad data, handle this situation as the caller needs. The thrown exception also provides additional information about what exactly failed to be parsed as long as context information (request, received message -- same as in other IQFeedExceptions).

from iqfeed.csharpapiclient.

@gribunin I'm about to push a slightly enhanced version as well. I'll add you as a reviewer.

from iqfeed.csharpapiclient.

@gribunin please check my PR.

from iqfeed.csharpapiclient.