best practices for Exception handling in .net service layer

Question

Working on reviewing some exception handling features in .net and want to know best practices for handing unknown exceptions.

Scenario : In service layer, I have the top most function as below. with catch statements that derive from exception and also exception, is this valid?

public CalcResponse DoSomething(int a, int b){
  var calcResponse = new CalcResponse();
  try 
   {
      var calcService = service.EvaluateSomething(a,b);
      calcResponse.Result  = calcService.Result;
   }
   catch(ArgumentNullException exc){
     //log and return meaningful error message, below is just an example.
     calcResponse.Result = "Invalid Numbers, try again";
   }
   catch(Exception e)
   {
     //log and return meaningful error message, below is just an example.
     calcResponse.Result = "Please try again...";
   }
}

So i have argumentNullexception and other exceptions handlers which i think can happen and handling them specifically. For unknown exceptions which can be anything else that I dint handle and don't want to send any information about my service to client, I declared catch(exception e). Is catch(Exception e), at the top most level a good practice?

Note: The service is handling and throwing only derived exceptions.

Update: My question is more around handling the top level exceptions and not about notifying the client in proper way. I'll try to notify based on technology stack(like rest or wcf).

is having Catch(Exception e) at the top level bad practice?

Answer 1

In your example above your are catching Exception and returning "Please try again." With that in place you will never be able to identify problems in your code because you'll never see your errors bubble up. Your customer will say "I got an error", but that error will never show up in your error log so you'll have no idea what went wrong. That's the main reason to not use try/catch blocks.

try/catch blocks are very useful in the right context but here are a few reasons to avoid them:

1. They are expensive
2. They hide your errors

It would be better to catch your argument null issues on the UI layer of the code. Leave your service layer free to do your business logic.

I suggest you check out Elmah, it's a great free way to log errors.

Answer 2

To me, you are implementing a second error handling. As a potential user of your service, that sucks.

I have to implement exception handling, because there are countless things that can go wrong contacting your service.

And now, I have to implement a set of if/else conditions, too, because you chose to return errors in a different way, too.

Please do not do this. There is a simple mechanism called Faults. Faults are translated to (and from) .NET exceptions. Do not add your own layer of error's that is not compatible with the standard.

If you want to control the errors your service reports (for example you don't want to give implementation details) that's fine. Catch them and throw an exception specific to your service. But stay with the proven mechanism and throw exceptions and/or faults. Do not introduce your own return codes . Your caller will need twice the work and you will gain nothing.