Apr 10, 2010

Nasty shock when handling WCF service exceptions ....

I just wanted to share a recent interesting experience while handling WCF service exceptions.

Here is the case.
Imagine you have to consume a WCF service. You need to handle if the service is gone and do some additional things (let's say you want to display a message).

Let's have an example. Imagine you have the following service:
http://someservice.com/Calculator
This service is used to calculate let's say the interest rate for a loan.
You want to be able to use the service and if the service is not there - you will want to store the borrower data in the db so you can re-submit it ...
What I did in order to test this scenario was to change :

http://someservice.com/Calculator
to
http://someservice.com/CalculatorUnavailable
so I can simulate that the service is gone.
In this case the .NET framework will throw System.ServiceModel.FaultException. It's OK, I handled it and pass it for testing.

After a few days we end up with the service gone again. And the bad news was that it was working on my machine. I needed to simulate it somehow and the problem was obviously some kind of restriction on the server.
Since we wanted to handle such scenarios as well, I wanted to somehow simulate it on my PC.

Finally after about half an hour of debugging I found out the reason.
It was the Server not able to find the domain name record for the service URL.
Then it was easy for me to figure out that if I change the url from :

http://someservice.com/Calculator
to
http://UnavailableSomeService.com/Calculator (note that it matters if you change the TLD (top level domain) or the path. You will have two different exceptions ;).
It appeared that in such cases the exception that .NET will throw is System.ServiceModel.EndpointNotFoundException.

I handled it as well and voilla!