Good use of try catch-blocks?

Question

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.

Answer 1

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.

Answer 2

Exceptions allow for writing cleaner code because the bulk of it takes care of the normal case, and the exceptional cases can be handled later on, even on a different context.

The rule for handling (catching) exceptions is that it must be done by context that can actually do something about it. But that has an exeption:

Exceptions must be caught at module boundaries (specially layer boundaries) and even if only to enclose them an throw a higher level exception that has meaning to the caller. Each module and layer must hide its implementation details even regarding exceptions (a heap module may throw HeapFull but never ArrayIndexOutOfBounds).

In your example, it is unlikely that upper layers can do anything about an SQLite exception (if they do, then it is all so coupled to SQLite that you won't be able to switch the data layer to something else). There are a handful of foreseeable reasons for things like Add/Delete/Update to fail, and some of them (incompatible changes in concurrent transactions) are impossible to recover from even in the data/persistence layer (violation of integrity rules, f.i.). The persistence layer should translate the exceptions to something meaningful in the model layer terms so upper layers can decide if to retry or to fail gracefully.

Answer 3

As a general rule you should only catch specific Exceptions (e.g. IOException), and only if you have something specific to do once you've caught the Exception.

Otherwise, its often best to let Exceptions bubble up to the surface so they can be exposed and dealt with. Some folks call this fail-fast.

You should have some kind of handler at the root of your application to catch un-handled Exceptions that have bubbled up from below. This affords you the chance to present, report or manage the Exception in a suitable way.

Wrapping Exceptions is useful when you need to throw an Exception across a distributed system and the client doesn't have the definition of the server-side fault.

Answer 4

Imagine that you are writing a stack class. You don't put any exception handling code in the class, as a result it could produce the following exceptions.

1. ArrayIndexError - raised when the user attempts to pop from empty stack
2. NullPtrException - raised due to a bug in the implementation causing an attempt to reference a null reference

A simplistic approach to wrapping exceptions might decide to wrap both of these exceptions in a StackError exception class. However, this really misses the point of wrapping exceptions. If an object throws a low-level exception that should mean the object is broken. However, there is one case where this is acceptable: when the object is in fact broken.

The point of wrapping exceptions is that the object should give proper exceptions for normal errors. The stack should raise StackEmpty not ArrayIndexError when popping from an empty stack. The intent is not to avoid throwing other exceptions if the object or code is broken.

What we really want to avoid is catching low-level exceptions which have been passed through high-level objects. A stack class which throws an ArrayIndexError when popping from an empty stack is a minor issue. If you actually catch that ArrayIndexError then we have a serious problem. Propogation of low-level errors is a far less serious sin then catching them.

To bring this back to your example of a SQLException: why are you getting SQLExceptions? One reason is because you are passing invalid queries. However, if your data access layer is generating bad queries, its broken. It shouldn't attempt to rewrap its brokenness in a DataAccessFailure exception.

However, a SQLException could also arise due to a loss of connection to the database. My strategy on that point is to catch the exception at the last line of defense, report to the user that database connectivity was lost and shutdown. Since the application has loss access to the database, there is really not much more that can be done.

I don't know what your code looks like. But it sounds like you might be blindly translating all exceptions into higher level exceptions. You should only be doing that in a relatively small number of cases. Most lower level exceptions indicate bugs in your code. Catching and rewrapping them is counter-productive.