Avoid Exceptions Whenever Possible

06 Aug 2006 7:49 - (0) comments

Some interesting quotes from the c2 wiki about exceptions.
An anonymous visitor writes:

...exceptions are conceptually and computationally more difficult to analyze because they depend on the program's runtime behavior. Loops and branches, and even intraprocedural gotos, can be understood simply by inspecting the procedure in which they appear. Exception handling depends on call the dynamic call graph - you might get an object in a class that will throw an exception one time and a different subclass that won't some other time. (Yikes! I think I am actually managing to convince myself!)
Anyhow, exceptions are more of a ComeFrom than a GoTo. The catch clause knows where it is, but the throw statement has no idea where the flow of control will end up - it's just a "go".

Ron Jeffries on where C3 uses exceptions:

One: The main exception handling in C3, which is only a couple of thousand classes of course, is this: surround payment of an individual with an exception handler. If an exception occurs, write the stack to a file, pay the next guy.

We don't care at the time of pay why he didn't pay, we just have to go on. When we want to know why he excepted, we just pay him again with the handler off and catch it in the debugger.

Anything else would be overkill.

Two: Another place is in deductions where a required deduction (savings typically) raises an out of money signal, sets a flag to turn off certain optional deductions, runs the deductions again. If it works, go with it. If it doesn't, he's dead.

Three: Finally, and I wish this weren't true, there's an exception handler deep in the I/O code. This handler allows the code to retry some obscure thing or other. It also has been known to mask all kinds of errors.

In my opinion, number One is perfect, Two is marginal, and Three is bad.

Further reading: ExceptionsMaskRealProblems
Don't Use Exceptions For Flow Control.