Question

I’m wondering what the correct way is to pass on an exception from one method to another.

I’m working on a project that is divided into Presentation (web), Business and Logic layers, and errors (e.g. SqlExceptions) need to be passed down the chain to notify the web layer when something goes wrong.

I’ve seen 3 basic approaches:

try  
{  
    //error code
} 
catch (Exception ex)
{
    throw ex;
}

(simply rethrow)

try  
{  
    //error code
} 
catch (Exception ex)
{
    throw new MyCustomException();
}

(throw a custom exception, so that a dependency on the data provider is not passed on)
and then simply

//error code

(not doing anything at all, letting the error bubble up by itself)

Naturally there’s some logging happening in the catch block too.

I prefer number 3, while my colleague uses method 1, but neither of us can really motivate why.

What are the advantages/disadvantages of using each method? Is there a better method I don’t know of? Is there an accepted Best Way?

Answer 1

If you do nothing you should simply let it go upper where some one will handle it.

You can always handle a part of it (like logging) and re-throw it. You can re-throw by simply sending throw; without having to explicit the ex name.

try
{

}
catch (Exception e)
{
    throw;
}

The advantage to handle it is that you can ensure that some mechanism is there to notify you that you have an error where you do not suspect to have one.

But, in some case, let say a Third Party, you want to let the user handle it and when it’s that case you should let it continue to bubble up.