Checked Exceptions Reality Check

Mark Hooijkaas, $Revision: 1.3 $, $Date: 2004/05/31 23:34:36 $

The beauty of exceptions

In the C family of programming languages (C, C++, Java, C#), exceptions were first introduced with C++. In C, and other programming languages without exceptions, dealing with errors or other “exceptional circumstances” was very cumbersome and error-prone:

• Functions use different kind of mechanisms to signal that some kind of problem has occurred, such as special return values or global error variables.
• Each function call must be surrounded by code to check for any error. Sometimes it is estimated that 90% of code is about dealing with exceptional circumstances.
• There is a very real possibility that programmers forget to check for an error every now and then (or consistently), thus ignoring the error.

Without exceptions writing a simple statement like

	config_file = fopen(filename, “r”);

	config_file = fopen(filename, “r”);
	if (config_file==NULL) {
		/* clean up */
		set_error(PROBLEM_READING_CONFIG_FILE);
		return;
	}

The use of exceptions solves all of these problems:

• uniform mechanism to signal errors
• no code clutter from continuously checking for errors
• no possibility to accidentally ignore errors

Checked and unchecked exceptions

In the Java programming language something new was added to the exception mechanism: the checked exception. A checked exception is any exception that inherits from Exception but not from RuntimeException. If there is a possibility that a java method can throw a certain kind of checked exception a programmer must explicitly mention this in the interface of this method (the “throws clause”). The compiler checks if a programmer has done this correctly, and reports an error if in the implementation of a method a certain type of exception can occur that is not explicitly handled by the programmer by either catching this error (or any parent class) or mentioning it in the throws clause (or any parent class).

A slightly different view on checked exceptions is that by mentioning a specific exception type in the throws clause of a method, forces any user of that method to handle that error by either catching it, or by mentioning it in it’s own throws clause.

Checked exceptions in practice

On first sight, I (and any other programmer I know) really liked this idea of the compiler helping a programmer in ensuring that all possible errors has been handled or acknowledged. Forcing a programmer to handling or acknowledging each possible type of error, should help make code more robust.

The idea of checked exceptions still seemed to be a great idea on second sight when compiling small and medium sized programs. It often is a pain to get all the throws clauses right. Also, when some implementation deep down changes one often has to change the throw clause of many methods to propagate a new exception up call trees. However the idea is that all this work to get a program to compile correctly would benefit the robustness of the program.

However, when one looks at the practice of large programs, with often many programmers working on the same program, certain problems in the use of checked exceptions appear:

• In large programs it becomes unworkable to list all possible exceptions in the throws clause of a method.
• The throws clause of a method may reveal details of some implementation detail deep down.
• When changing the implementation or another detail of some function that changes the exceptions that might occur, this might impact all methods that use this function directly or indirectly. This might result in a massive amount of methods (sometimes over 100) of which the throws clause needs to be changed.

Exception Wrapping

The following code fragment is an example of exception wrapping

	try {
		readConfigFile(filename);
	}
	catch (IOException excep) {
		trhow new ConfigFileException(excep);
	}	

In Java one must use some kind of exception wrapping to mitigate the problems of checked exceptions as mentioned in the previous section:

• By wrapping many different kind of exceptions into a new "higher-level" exception type, the throws clause can often be shortened.
• By wrapping exceptions caused by implementation details, these exceptions are no longer visible in the throws clause.
• When the throws clause of a method changes, the callers may wrap this extra exception, so that this changes does not need to be propagated over the entire call trees.

Why I still don't like checked exceptions

1. A checked exception forces the calling method to conciously handle that exception, by either catching it, or acknowledging it in the throws clause.
2. In 99% of the methods a method cannot sensibly handle an exception other than passing it through to it's caller (either wrapped or not).