In Failure and Exceptions, James Gosling argues the case for checked exceptions. (Bruce Eckel makes the opposite case in Does Java need Checked Exceptions?).
Gosling's argument seems weak to me. He claims that it's impossible to test every circumstance, especially the unexpected, (which is true), and that exceptions can keep a program working in the face of this. Well, checked exceptions can keep a program from falling over, but that's not the same thing as keeping it working. I'd prefer a program to fall over than for it to keep on truckin', writing crap to a database. This has happened to all of us, I'd imagine, and a clean failure is far preferable.
Besides, in the real world, there often isn't anything you can do in the face of many exceptions, but the compiler insists that you have a catch block for them somewhere anyway. The number of times I've seen them empty...
The workaround in Bruce Eckel's article works fine, but I'd rather have the choice as to how to deal with exceptions, as Python gives me.
Posted to Java by Simon Brunning at September 25, 2003 12:38 PMGod bless Python, saving the day again ;-)
Posted by: Mark Matthews on September 25, 2003 02:50 PMShame. Mark missed an opportunity to get in a pro Microsoft/C# jab there.
Posted by: Simon Brunning on September 25, 2003 03:26 PMI use the IntelliJ early-access builds. And hell, let me tell you, I'm damn glad it doesn't fall over if I stumble across an exception they've missed in what is essentially a nightly build. I'd lose source changes for the last 10 minutes if it did that!
Clean failures are nice for developers, they suck for end users. Because most exceptions aren't really that catastrophic.
The real trick (imho) is architecting software in such a way that it isn't so brittle that some bad data here or there causes it to die.
I *don't* mean handling all the things that can go wrong (because that way is prone to failure), I mean thinking real darn hard at the start of it all to not only come up with all the crazy stuff that can go wrong, but to architect the system so that it's impossible for that to screw it up.
Example: Commit/Rollback for databases. Good architecture. Trying to handle failures at the client program level and manually roll-back what you've done: nearly impossible to do without glitches, nearly impossible to test.
And by the way, Empty catch blocks are PURE EVIL! At least e.printStackTrace()!!!! If I ever find an empty catch block without an explicit documentation comment saying "it's safe to ignore this in ALL circumstances because of X", I use the source control system to track down who wrote it and yell until, even if they can't understand why it's such a terrible idea, they'll think twice in the future just to avoid me screaming at them about it.
Posted by: Paul Mclachlan on September 25, 2003 04:58 PM[Paul Mclachlan threatens the lives of those writing empty catch blocks]
Hear hear! no empty catch blocks! A good java lint would flag that as an error, and would force you to at LEAST put in a comment.
Posted by: Michael Chermside on September 25, 2003 05:22 PM