Download your favorite Linux distribution at LQ ISO.
Go Back > Blogs > CoderMan
User Name


Rate this Entry

Exception Handling: How Far Do You Go?

Posted 01-14-2010 at 11:25 PM by CoderMan
Updated 01-14-2010 at 11:26 PM by CoderMan

A question I've pondered a few times, revisited in my recent work in Java, which seems to have a pretty solid exception handling system: How deep do you go in handling exceptions? As I see it, there seems to be a few categories:
  • Errors cause by bad input from the end-user. (Enters data he is not supposed to, clicks on things he shouldn't, etc.)
  • Errors cause by external circumstances that are expected to happen from time to time. (Network connection was dropped, etc.)
  • Errors caused by a programmer using the code. (Passes in bad parameter, fails to initialize an object properly, etc.)
  • Errors that could theoretically happen but shouldn't. (RAM error causes data corruption, image data files is corrupted, etc.)

I think the answer likely depends a lot on the magnitude of the impact that would be caused by the appearance of the error in question. But I haven't entirely solidified my philosophy.
Posted in Uncategorized
Views 3654 Comments 1
« Prev     Main     Next »
Total Comments 1


  1. Old Comment
    It is an interesting question. It has been a while since I've thought about it, but my view is this:

    1) Exceptional conditions are not the same thing as error handling (ie, categorizing errors is not the correct way to categorize exceptions). An exceptional condition is any state that is atypical at a particular point in the code.

    There are some classes of errors that can be handled more elegantly at the place where they are detected. For example, zero value errors can sometimes be handled by simply returning, because even if the zero value is unexpected, this (non)behaviour is consistent with how the function would work had the zero value been normal.

    Likewise, there are rare circumstances where an exception mechanism is a more elegant way of handling a normal but infrequent condition. For example, the end of file might be done through an exception.

    I use exceptions where they would be more elegant than other forms of control flow. This happens when the exception condition relates to a function that is not the one which detects the condition, and there is no sensible action that can be taken locally.

    2) I would distinguish only two types of exceptional state; expected ones and unexpected ones. Expected ones roughly correspond to your first two types of errors (input errors and external circumstances). Unexpected ones roughly correspond to your second two (programmer errors and hardware errors).

    Handling expected exceptional states (whether with a language exception feature or in some other way) is not a problem; just pick the most elegant way of handling them, since one knows the behaviour that is required.

    Handling unexpected exceptional states is trickier. By definition if the state is unexpected, it is not clear what the behaviour should be, however it is handled.

    Some code just throws an exception anyway, in the hope that the parent functions somewhere will know what to do! But this can be disastrous; an example is the Ariane 5 failure, where the reuse of old Ariane 4 code in a new physical context tripped an unhandled exception, causing the (redundant) computer systems to all crash.

    My feeling is that unexpected states should generate debug output, so that at least such issues can be examined during testing. But it is not always clear what should happen in a non-test situation. It may be that a fail-safe mode is required (as in an ABS system in a car), or it may be that the code should just continue (as in a word processor where you don't want to exit and lose the document just because the spelling checker had a problem).

    It is also not clear where the unexpected state should be checked (eg using asserts). The easiest is to do so at the entry and exit of a function. But there may also be intermediate points where it makes sense to check for certain conditions or invariants. To do this thoroughly is not trivial, and still relies upon subsequent and comprehensive testing.
    Posted 01-20-2010 at 08:39 AM by neonsignal neonsignal is offline
    Updated 01-20-2010 at 08:45 AM by neonsignal


All times are GMT -5. The time now is 12:29 AM.

Main Menu
Write for LQ is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration