Error handling, why at all?

by Karel Thönissen

In this thread in the Joel on Software forum KayJay wrote:

Error handling - why at all?

http://weblogs.asp.net/oldnewthing/archive/2004/04/22/118161.aspx#FeedBack

Valid points. But why handle exceptions at all? If one codes with strict requirements and validations, a la DBC, why not just let the app die after dumping the state to a log? Or is exception handling by definition a validation routine?

I posted (except for little editorial changes):

In this discussion I miss the distinction between exceptions and violations. Violations are when the assumptions of the programmer appear not te be correct. In that circumstance, any form of handling is a form of uneducated guessing. How can one safely repair the program's condition if one obviously has lost track? Violations are raised by contracts. Exceptions are less serious and rather common, i.e. broken connections, printers out of paper, locked files, etc. These are conditions that are not usual, but they should be anticipated. Exceptions are rather common and should be handled. Handling violations usually is not a good idea, unless your software controls a mission critical device for which a mem dump is not an option. E.g. if your software controls a space craft reentering the atmosphere, then guessing can be better than shutting-down, because the latter has a 100% chance of disaster.

In our company we make our software as brittle as possible. We hardly have any exception handling mechanisms in our code base. Let it break, let it break, let it break! False assumptions are shown instantly, and they are not concealed by repair code. Nice side effect: we do not have to write repair code. Repair code is often buggier than the code it must repair. The programmer is already dealing with a difficult program state, the code is difficult to test, and coverage is a serious problem.

So if our software breaks, we remove the bug, rather than add repair code.