This project is read-only.

Request for try/catch or similar

Aug 8, 2013 at 7:35 PM
Markus,

This is not a big deal, but thought I would ask.

If the backend delays responding for a period of time (say I am debugging some code, whatever) on line195 of ServiceTestHarnessUI, I get an error:

System.Reflection.TargetInvocationException was unhandled
HResult=-2146232828
Message=Exception has been thrown by the target of an invocation.
....
   InnerException: System.Net.Sockets.SocketException
        HResult=-2147467259
        Message=An existing connection was forcibly closed by the remote host
...

So the host forced the connection to close. No problem. But at that point, if I just try to continue and have it try again, it keeps getting the error - so apparently something is set that prevents me from continuing.

It would be nice if there were code in there to handle this issue so that, should the service time out, I would get an error (just like I do now), but then would be able to try again or cancel the process.

Thanks,

Fletcher
Aug 12, 2013 at 12:17 AM
If you have a reference to a channel and then the channel enters faulted state for whatever reason and then you use the channel again, there isn't really an opportunity for me to run any code that could fix that and make your reference work again. So while I agree that it would be nice to do so, it is probably something you have to handle wherever you use the channel.


Markus
Aug 14, 2013 at 12:32 AM
Markus,

I was thinking of a Try-Catch around the code that tried the communication. If the BE timed out, it could catch it. In a dev environment, we could just use Set Next Statement. In a end user environment, we could put code to alert the user that they are disconnected and to reconnect.

A variation I will need to implement is one where if the BE is unavailable (at startup OR anytime thereafter), that I catch the problem and instead reference a local DB. Once the app can again connect to the BE, it will re-sync the local data to the BE - in most cases without bothering the user (although we will have an indicator to let them know we can't reach the BE.) In some cases (especially mobile), it is quite possible that the connection to the BE will come and go.

For this specific app, the user must be able to operate, whether or not they can communicate with the BE. Since I will have to do it at some point, if you give me some hints, once I have it working I can send you the code to use/ignore as you wish.

Thanks,

Fletcher