0

In the application I"m working with, there is some communication with the remote service using WCF (basic http binding, no fancy stuff). Since the client is lightweigh, the details of the server are irrelevant, you may assume that there is just a method that always return true (like ping or something).

The proxy is generated using a Task option, the new client instance is created each time the operation is called. Something like this could be spinning inside the timer:

void Foo()
        {
            var client = new PingServiceClient();

            try
            {
                bool result = client.PingAsync().GetAwaiter().GetResult();
            }
            catch
            {
                //log something
            }
            finally
            {
                client.Abort();
            }
        }

My question is, how should I correctly handle the cases when the network is down? Because the behavior is different. I either get an application crashing (I assume on a task finalizer, which is for some reason not handled neither in AppDomain.CurrentDomain.UnhandledException nor in TaskScheduler.UnobservedTaskException), or sometimes it just silently outputs tons of error messages, but not crashing anything. Messages like these:

Exception thrown: 'System.Net.Sockets.SocketException' in System.dll
Exception thrown: 'System.Net.Sockets.SocketException' in System.dll
Exception thrown: 'System.Net.Sockets.SocketException' in System.dll
Exception thrown: 'System.Net.WebException' in System.dll
Exception thrown: 'System.ServiceModel.EndpointNotFoundException' in System.ServiceModel.dll
Exception thrown: 'System.ServiceModel.EndpointNotFoundException' in System.ServiceModel.Internals.dll
Exception thrown: 'System.ServiceModel.EndpointNotFoundException' in System.ServiceModel.Internals.dll
Exception thrown: 'System.ServiceModel.EndpointNotFoundException' in System.ServiceModel.Internals.dll
Exception thrown: 'System.ServiceModel.EndpointNotFoundException' in System.ServiceModel.Internals.dll
Exception thrown: 'System.Net.Sockets.SocketException' in System.dll
Exception thrown: 'System.AggregateException' in mscorlib.dll

I'm struggling to find a graceful way of handling these, so if anybody has some knowledge regarding this please share the approach.

Thanks in advance.

UPD: I have tried to re-create the proxy with Begin/End pair and override the end method implementation in a partial class:

public partial class PingServiceClient : IPingServiceClient, PingService
    {
        public Task<bool> PingSync()
        {
            return Task.Factory.FromAsync(BeginPing(null, null), HandledEndPing);
        }

        private bool HandledEndPing(System.IAsyncResult result)
        {
            var res = false;

            try
            {
                res = EndPing(result);
            }
            catch (Exception e)
            {
                ;
            }

            return res;
        }
    }

Still the same barrage of messages in the output as before (the catch is working, though).

Pritorian
  • 414
  • 8
  • 19
  • You could try and read the following about handling exceptions with a typed client: https://learn.microsoft.com/en-us/dotnet/framework/wcf/samples/expected-exceptions And here is the code which the article is referring to: https://github.com/dotnet/samples/blob/6813978f9003a6ba0c01b15f5b89cb4fe816cdbb/framework/wcf/Basic/Client/ExpectedExceptions/CS/client/client.cs – Rogn May 12 '22 at 17:55
  • [WCF Error Handling](https://learn.microsoft.com/en-us/dotnet/framework/wcf/wcf-error-handling) – Lan Huang May 13 '22 at 06:21
  • Communication errors occur when a network is unavailable, a client uses an incorrect address, or the service host is not listening for incoming messages. Errors of this type are returned to the client as [CommunicationException](https://learn.microsoft.com/en-us/dotnet/api/system.servicemodel.communicationexception?view=dotnet-plat-ext-6.0) or [CommunicationException](https://learn.microsoft.com/en-us/dotnet/api/system.servicemodel.communicationexception?view=dotnet-plat-ext-6.0)-derived classes.You can use a try-catch block to catch exceptions. – Lan Huang May 13 '22 at 06:21
  • "A proper way to handle WCF network related exceptions" - by running away from WCF, as quickly as your legs can carry you. – Dai May 13 '22 at 12:21
  • @Dai come one, it isn't that bad ) And where to, gRPC? – Pritorian May 13 '22 at 12:24
  • @Pritorian gRPC is still far better than SOAP. – Dai May 13 '22 at 12:25
  • @Dai would love to try that on a greenfield project, but for now I have to deal with this one and I'm just wondering why there is no clear way to get rid of mass exception flood in output ( – Pritorian May 13 '22 at 12:28
  • @Pritorian Attach your VS debugger and enable "Break on first-chance exceptions" - and load Symbols for all the .NET Framework libraries - that will enable you to see what's going on. – Dai May 13 '22 at 12:32
  • `bool result = client.PingAsync().GetAwaiter().GetResult();`<--- *aieeeeeee* _don't do this_. You **need** to invoke `PingAsync` within an `async` context. Don't try to force `async` code to run in a non-async context, it's a fool's errand. – Dai May 13 '22 at 12:34

0 Answers0