Frank Sommers
Posts: 2642
Nickname: fsommers
Registered: Jan, 2002
|
|
Re: The Trouble with Checked Exceptions
|
Posted: Aug 21, 2003 12:53 AM
|
|
Whether checked exceptions are useful or not depends on a more fundamental question: Useful for what?
If one's goal is to make a programming language popular for programmers (so that programmers start using it, and start to like it), then I agree that things should be kept simple - just don't cause many troubles for the programmer, just keep things simple and smooth. Then checked exceptions are more trouble than they're worth.
On the other hand, if one's goal is to build systems that can survive all kinds disasters and exceptional conditions without a blink, then checked exceptions are very useful, indeed. They're useful, because they give you a programmatic interface to failure. And that interface makes it possibly easier to recover from those failures.
Traditionally, the latter category of software contained things like operating systems, file systems, real-time systems, etc. For instance, it's hardly acceptable to just pop up a dialog box, "Sorry, disk sector XXX failed. Please reboot." Rather, you just want to hide that error from the user, and route around it. Indeed, disk controllers just handle such things themselves, mapping around bad disk sectors, without even letting an OS know about the problem. Traditionally, end-user applications are much less industrious: You can always pop up that message dialog and push exception handling up the chain to the user.
But the standards are changing, and end-user software will have to become as reliable and OSs, file systems, disks, or embedded systems. For instance, today it's still OK to pop up a dialog to the effect: "Can't save file. File system full." That may no longer be acceptable in a few years: People don't care about file systems, they just want the system to save their darn file (even if it means that the system now has to borrow another machine's file system perhaps).
As an increasing number of people use software, users' tolerance is going to diminish: They will demand software that can fix its own problems. In turn, they will demand that programmers actually consider the exceptional conditions AND write the software so it recovers from those exceptions.
This is already happening in the industry I am in. Displaying an error message "Cannot connect to database" might be acceptable in an environment that caters to programmers or system administrators. But displaying that message to end-users who don't know what a database is, or why you would have to "connect" to one, is going to be a serious problem. Such users lose patience very quickly, and dial the tech support line with great indignation: "Your system doesn't work. I'm losing money, I can't conduct business. Come out here right away, and fix this." They can't and won't follow instructions - they will want you to go out to their location and fix their problems, even if it means only a database reboot.
From a business point of view, that's going to be an extraordinarily unprofitable venture. So, instead, you probably want the program to declare that connection exception, and then think of all the ways your program can reconnect to that database, and create an exception handler that's activated by that connection exception. Or, if all fails, ship a log file back to your support office even BEFORE the customer notices the error (or at least before they call).
I like to declare only those exceptions where there is a reasonable chance of automated recovery. But once I declare those exceptions, that says, in essence, that the corresponding recovery routines are now a system requirement - the system doesn't meet its requirements without them.
I do agree that declaring exceptions from which automated recovery is hardly possible, is an undue burden, and such a practice completely obliterates the value of checked exceptions: It simply invites programmers to leave empty catch clauses in their code.
In summary, as the standard for software quality rises, checked exceptions will continue to play an important role in making software more robust and reliable. They can be an inmune system to software. And an abused immune system is just as bad as an organism without one altogether.
|
|