Question

I was using the following pattern for catch blocks in my data class:

} catch (OracleException e) {
    log.Error(e, e);
    ExceptionNotification.Show(e, "Platypus data not found for Platypus");
    throw;
}

(the “log” is log4net; after that is our fancy exception display dialog).

When I remove the “throw,” I get “not all code paths return a value”

If I reach the exception block, the object I want to return (an OracleDataTable, a List, a Dictionary<>, or a custom class, usually, might be null, or at best not feeling too well. What can I return to mollify the compiler?

Answer 1

Never mollify compilers. Boss them around and make them do what you need, or they’ll get above themselves.

Compilers have a submissive nature, and like being bossed; the moment you start mollifying them they stop helping you. Some of them even bring their own paddles.

If you have to ask this question, you’re probably taking the wrong approach. The answer to “what value to return on swallowing an exception” is “the value that is blatantly obvious as the value to return in swallowing this exception in this place”. If nothing is that obvious, then it shouldn’t be swallowed (the same applies to “the obvious place in the loop to continue from after swallowing this exception in this place”). And then double-check your assumptions because the “obvious” thing can still be wrong.

You should also comment any swallowing clearly, because it’s so often a bad thing that anyone reading the code is going to start with the assumption that it’s bad code unless you explain why it isn’t.

You’re better off with one of the following:

throw;

Let the exception pass up. Something handles it, or something doesn’t and you get an error message and a shut-down (not always the worse thing, depending on the application and how likely the error seemed to be).

throw e;

Which would throw the exact same exception (literally the same instance) but will be seen as coming from your code rather than the code you called into. This is so rarely the right thing that some people will tell you it’s plain wrong. I disagree, but I do agree the cases are rare – like swallowing, if it isn’t the obvious choice it’s almost certainly the wrong choice and if it is the obvious choice it might still be the wrong choice.

throw new ExceptionTypeAppropriateToThisMethodCall("a useful message");

OR

throw new ExceptionTypeAppropriateToThisMethodCall("a useful message", e);

Here you turn the exception into something more closely related to the service your method supplies to the calling code. The second form wraps the inner exception for diagnostic goodness.

In some cases, just killing the application or unloading the app-domain can be the best choice, though that’s mostly going to happen from not having anything handle the exception at any point.