Is it a good practice to catch all exceptions and re-throw them as a particular type of exception in terms of classification?

Question

Hi!

Is it a good practice to catch all exceptions and re-throw them as a specific type -basically to classify all the exceptions thrown from a particular part (or service) of an application?

Something like:

//  This class is used to label all the exceptions occured on 
// Race Cars Service calls as RaceCarsServiceException
public class RaceCarsServiceException : Exception
{

 public class RaceCarsServiceException (Exception e) 
               : base("Something went wrong!", e)
  {
     // Basically I assign the exception e as the inner exception 
     //by using the constructor method of Exception class
  }

}

public class RaceCarsService
{

// Some member fields, methods etc. here

 public double GetMaxSpeed(CarModel model)
 {
   try 
     {
       return (double)_carsWebService.GetMaxSpeed(model.ToString());
     }

   catch(Exception e)
     {
       throw new RaceCarsServiceException(e); // So all exceptions are rethrown 
                                           //as type of RaceCarsServiceException
     }
 }
}

Answer 1

This code sample do not rethrow exception but create new one base on other.

That code will create new stack trace.

good practice for exceptions

Answer 2

This is one of those huge argument startingt questions.

If you are throwing custom exceptions they should not map directly from an internal expcetion as in your example. You should be doing some kind of conditional check to differentiate your specific need for that specific custom exception from the wide variety of possible exceptions that could be thrown.

In my view doing this can be very beneficial if done in moderation in the right places.

fo rinstance in one application i built we had a requirement of being able to back track every function call with the parameters passed in so that we can identify the precise chain of events leading to an exception.

sometimes the internal exceptions are not granulated enough. Or you need to throw an exception that tells you what kind of process failed.

Eg if you have code that is required to be transactional but works accross multiple services and so requires some manaul code to take care of things then a transaction exception is appropiate, as is a transaction rollback exception (which uually means you are in a world of pain).

Howver I know people that strongly feel that custom exceptions are a bad thing. The reason being that it is easy to get carried away and create too many custom excpetions which are meaningless and useless to everybody else.

One thing I foudn is that a RecordDoesNotExist exception feels like a DAL exception but in reality it occurs and is handled most often in business logic.

so in summary i think they are a good idea in the right places, in moderation and with good reason. But its easy to get a bit ott with them.

you should always pass the origional expcetion into your custom exception and store it there. This DOES preserve the stack trace as well as storing a stack trace in your exception for the point at which the custom one is thrown.

I use custom excpetions when auditing them is a requirement.

EDIT: After following links in the other answer i gotta say this is a great article on excpetions

Exception Handling Best Practices in .NET

Along with this one about anti - patterns

Exception Anti-Patterns

Answer 3

No necessary to do that (at least in your example). When trying to invoke a method which probably throws exceptions, dealing with different kinds of exceptions separately.

try
{
    AMethodMayThrowExceptions();
}
catch (FileNotFoundException fileEx)
{
      //maybe create the file and retry
}
catch (TimeoutException timeoutEx)
{
      //maybe a retry after n seconds
}
catch (Exception ex)
{ 
      //other exceptions which I don't care
      //just a prompt of ex.Message or something
}

What things will be if you use a single RaceCarsServiceException?

catch (RaceCarsServiceException ex)
{
    // now it's supposed to have a `ErrorCode` property, or an inner exception
    if (ex.ErrorCode == ErrorCode.File)
        //file exception, everything is the same with FileNotFoundException
    else ...
}

You got nothing but trouble, and less readable codes!