[from discussion in DontThrowGenericExceptions]

As has been noted exceptions are control structures like "if" or "goto", they don't really imply anything about what is happening in the code by virtue of their existence -- they just indicate that control is being shifted from one place to another and give (alarmingly little) information about what code will receive control next. The big deal about exceptions is that they can make very dramatic shifts in control and there isn't any information at all about where the control is going at the point where an exception is thrown. They are also profoundly slow in many environments -- sometimes as much as three orders of magnitude slower than "ordinary" control structures.

Clearly these factors limit the usefulness of exceptions as control structures. 

When an exception is caught the catching clause must either propagate an exception itself or take some action to allow the method that contains it to continue in some meaningful way. If all catch clauses propagated exceptions then the only possible result of an exception would be the eventual termination of the program and the only other interesting detail about the exception would be what error message to present to the user upon termination. But catch clauses don't have to propagate exceptions, they can, instead, return control to the "normal" program code at a point immediately following the try clause. The net effect is to terminate whatever operation was being attempted in the try clause. If we want to keep the program running after handling the exception (and this applies to any error handling scheme -- not just exceptions) we must leave it in a state that is consistent and knowable. That is to say that the programs invariants must not be violated and the program itself must behave properly given its state after the error has been handled. It turns out that database rollback rules guarantee exactly these properties. I know of no other way to guarantee them, hence my assertion that ExceptionsCancelTransactions and that ErrorHandlingIsTransactionRollback.

''The ''''''ConcurrentModificationException'''''' thrown by java.util.Iterator illustrates this idea succinctly.''

This of course leads to the questions of WhenToCatchExceptions and how to implement ExceptionRecovery.  -- PhilGoodwin

"Cancel transactions" and the database metaphor suggests to me that the transaction is atomic. Exceptions don't have to be used like that. If, for example, an exception occurs in a word processor while converting the text to capitals, it might be reasonable to leave half the text in capitals and half as it was. -- DaveHarris

----

CategoryException