« July »
Locations of visitors to this page

Powered by blojsom

Radovan Semančík's Weblog

Friday, 8 July 2011
« Cycles | Main | MidPoint »

I was a very young student when I came across a book named Programátorské poklesky (Programmer's Misdemeanours) by Ivan Kopeček and Jan Kučera. The authors describe in a humorous way what are the results of programming errors. It was probably my very first book about programming that was not a programming language manual. It was a year after our country woke up from the communist era and programming books were difficult to come by. I think the book had influenced me more than I have anticipated or was willing to admit at the time.

One of the parts that I particularly remember was the software "psychology". Authors observed four temperaments of programs:

  • Sanguine programs provide readable and helpful error messages, have useful help texts, try to recover from errors and try to communicate reasonably in general. Yet, user interaction is maybe the only useful part of such programs.
  • Choleric programs does its job well. Such programs do not crash, but the error messages are very dense and cryptic. They do not provide any additional information and there is no help text. It does not try to recover from errors - it expects that the user will know what to do. Experts find these programs easy to use, but all other people hate it.
  • Melancholic programs get very sad when they encounter the smallest of problems. The program just crashes, does not provide any message or description. They refuse to communicate about the problem any further and usually does not even provide a way to resolve it.
  • Phlegmatic programs ignore any errors. They just carry no matter the cost. No error message, no indication, it just works on. Of course they may provide wrong results from time to time, but they run. That's the most important thing.

All of that came to my mind as I was discussing the error handling approach in mainstream programming languages (mostly Java). It usually boils down to handling exceptions.

The original approach in Java was to use checked exceptions. Programmer has to either catch them or declare them to be thrown. The authors of Java hoped that it will lead to a better error handling. But it looks like there is a glitch: error handling is very difficult to do right. It takes a lot of time and the error handling code may well be a significant part of the system. This leads to sanguine programs: they provide good information about errors, but they do little else. There is just not enough time and resources to do everything right.

Laziness is one of the three great virtues of the programmer. Therefore programmers soon stared to focus on the "meat" and simplified the exception handling. The easiest way at hand was to ignore all the exceptions. Catch all exceptions and handle them with empty code block. This obviously leads to a phlegmatic program. It will run no matter what happens. But the results may not be the best.

The current trend is to switch all the exceptions to the runtime exceptions. These do not enforce checking and handling. The usual outcome is that nobody checks or handles them. Any exception will bubble up through the call stack to the upper layers until is is caught by the framework. That may be an application server that will display a nicely formatted error message that essentially says "something somewhere went wrong" and terminate the request. The user has no idea what went wrong and where or how to recover from the problem. This is a melancholic program.

Luckily, some programmers display at least the exception type and message to the user. But what will the user do if presented with the message "ConsistencyException: Consistency constraint violated"? It is not really helpful. Most programmers also display or log a complete stack trace. But that won't help the user a bit. Even members of a core programming team have problems understanding that, user does not stand a chance. That gives us a choleric program.

Obviously, one size does not fit all. There is no single right way to do it. If a good error handling is required then a sanguine approach is needed. But there is a cost to pay: either reduced functionality or much more effort to do the "same" thing. Robust system asks for somehow phlegmatic approach while cheap code is best done melancholic. However, the usual approach is choleric code. Errors are reported, but nobody really understands them. You just can't always win.

Posted by rsemancik at 10:28 PM in Software
Comment: Leonardo at Tue, 25 Sep 2:12 PM

The problem isn't with epcextions, it's with this can't happen so who cares type thinking. It shows up in if-else-if constructs and switches as well.switch ( foo ) { case BAR: handleBar(); break; case BAZ: handleBaz(); break; default: /* can't happen */}There are times when one doesn't *care* if some code throws an exception, but this is normally a tiny, tiny fraction of the time. The advice to print the stack trace to a log file (or even stderr) is an excellent policy.The rest of the time, we presumably care, but either don't know what to do about an exception, or our API doesn't allow for checked epcextions. Wrapping that checked exception is better than ignoring it:try { someObject.mightThrowCheckedException();} catch (SomeCheckedException scx) { throw new RuntimeException( scx);}And if it truly is a Can't Happen , why, an error is called for:try { someObject.saysItThrowsCheckedExceptionButItLies();} catch (LyingCheckedException lcx) { InternalError ie = new InternalError( Programmer Assumption Violation ); ie.initCause( lcx ); throw ie;}Or better yet:public class PAVError extends InternalError { public PAVError( Throwable t ) { super( Programmer Assumption Violation ); initCause( t ); } }It would be nice if the difference between a checked and an unchecked exception were in how the exception is thrown, rather than the ancestor of the exception.

Add your comment:
(not displayed)
Generate another code

Please enter the code as seen in the image above to post your comment.
Your comments will be submitted for approval by blog owner to avoid comment spam. It will not appear immediately. Also please be sure to fill out all mandatory fields (marked by asterisk). This ... ehm ... imperfect software does not have any error indication for missing input fields.


[Trackback URL for this entry]