Good use of try catch-blocks

clean codecode-qualityexceptionsreadability

I always find myself wrestling with this… trying to find the right balance between try/catching and the code not becoming this obscene mess of tabs, brackets, and exceptions being thrown back up the call stack like a hot potato. For example, I have an app I'm developing right now that uses SQLite. I have a Database interface that abstracts the SQLite calls, and a Model that accepts things to go in/out of the Database… So if/when an SQLite exception occurs, it has to get tossed up to the Model (whom called it), who has to pass it off to whoever called the AddRecord/DeleteRecord/whatever…

I'm a fan of exceptions as opposed to returning error codes because error codes can be ignored, forgotten, etc., whereas an Exception essentially has to be handled (granted, I could catch and move on immediately…) I'm certain there's got to be a better way than what I've got going on right now.

Edit: I should have phrased this a little differently. I understand to re-throw as different types and such, I worded that poorly and that's my own fault. My question is… how does one best keep the code clean when doing so? It just starts to feel extremely cluttered to me after a while.

Best Answer

Think of it in terms of strong typing, even if you aren't using a strongly typed language - if your method can't return the type you expected it to, it should be throwing an exception.

Also, rather than throwing the SQLException all the way to the model (or worse, UI), each layer should catch known exceptions and wrap/mutate/replace them with exceptions suited to that layer:

Layer      Handles Exception
----------------------------
UI         DataNotFoundException
Model      DatabaseRetrievalException
DAO        SQLException

This should help limit the number of exceptions you are looking for in each layer and help you maintain an organized exception system.

Related Solutions

C# – How to simulate events that cause exceptions to test try/catch blocks

1) If you followed the dependency injection model, you could substitute real implementations of certain parts with the mocks which would throw exceptions as you need them. That would however require of you to initially design your application in a specific way or completely reengineer it.

Like:

public class SqlUsersRepository : IUsersRepository
{
    public void RegisterNewUser (User newUser)
    {
        throw new SqlException ("Connection timeout");
    }
}

Here however we would have the problem that the consumer code shouldn't concern itself with handling concrete implementation exceptions.

2) Another approach is to replace certain method calls with your custom wrappers.

Instead of:

FileStream fs = File.OpenRead (path);

you use:

FileStream fs = File.OpenRead_Test (path);

by providing a custom extension method (just a quick idea):

public static FileStream OpenRead_Test (this System.IO.File file, string path)
{
    throw new FileNotFoundException ();
}

Java – Exception versus return code in DAO pattern

On the conventional wisdom that states that you should only throw an exception when a condition occurs that you can't handle in your code we tend to focus on the definition of an exceptional condition but ignore the definition of what it means to handle the exception. A process may encounter a exception communicating with a particular node and may handle the exception by redirecting its request to a backup node instead. However, if a call to create an entry in a table fails because of a unique constraint as a result of a value entered by a user the only entity that can truly handle the condition is the user. Therefore this is grounds for throwing an exception as you cannot handle it in your code.

The semantics of your code also matters. Sticking with the example of creating a new user entry; a call to isAvailableUserName(userName) should not throw an exception if the userName already exists in the database whereas a call to createNewUser(userName) probably should. One reason to throw an exception instead of using a return code is that return codes in themselves provide inadequate information and require a lookup table or an enum that then becomes a dependency magnet. Exceptions on the other hand are more descriptive and contain a message, a backtrace, nested exceptions, etc. Exceptions also make your code cleaner. Instead of having lots of nested ifs that exist solely to test conditions, your code can function the way its supposed to and halt execution when a bad thing happens. Robert C. Martin in his book "Clean Code" states that error handling should not obscure the logic of the code. The cleanliness of the code also applies to the caller as return codes force the callers of the code to have to check for errors immediately after the call. Since this can easily be forgotten or ignored, its not a good approach. However, an exception cannot be ignored but must be handled.

Best Answer

Related Solutions

C# – How to simulate events that cause exceptions to test try/catch blocks

Java – Exception versus return code in DAO pattern

Related Topic