Only catch errors that you know how to handle. If you don't know how to handle it, it <i>should</i> propagate higher up the stack, even if it kills the execution of the program.<p>This implies that having a catch-all around your entire program is a <i>bad idea</i>. Doing so loses the stack trace; you no longer know where the exception was thrown from. I've had to debug programs that did this, and the first thing I did was comment out the catch all so a simple stack trace could tell me where to start looking.<p>In the compiler I'm writing right now, I do wrap the entire execution in a try-catch block, but the only errors I catch are ones I call "user_error". That represents an error in the input; I don't handle that kind of input on purpose, and providing it is user error, not compiler error. I don't catch the other kinds of exceptions I throw, which indicate what gcc calls "internal compiler error." It's much easier for me to figure out what I did wrong that way.
The biggest problem we have dealing with checked exceptions in Java is that it complicates interface inheritance when working with third-party class libraries. What do you do if you have to write a concrete class to implement an interface, but the interface's methods don't declare the exceptions you need? The interface isn't under your control, and the interface method signatures can't be changed anyway due to backward compatibility concerns.<p>What I usually do is cheat by catching the checked exception within the method, and then throw it again by using exception chaining to wrap it into an unchecked exception (RuntimeException). But it's hard to see that as a good solution.
From the article: "With the hindsight of a decade, we can see that it’s a disaster. The trouble is that every time you call a method that throws an exception, you create an immediate crisis: you break the build. Rather than conciously planning an error handling strategy, programmers do something, anything, to make the compiler shut up."<p>Frankly, this is the weirdest complaint I've ever seen about checked exceptions. If you're trying to build a system with crappy programmers, you're kind of screwed anyway, but checked exceptions actually help you out quite a bit, because you don't have a problem with stray exceptions taking down entire subsystems. You might miss a lot of meaningful errors and get corrupted data, but at least the system keeps running, and that's the most you can hope for if your programmers are as crappy and lazy as the article describes.<p>And contrary to the article, few programmers are really that lazy and irresponsible. In my experience, far more code is written by responsible programmers who are inexperienced, rushed, or lacking a complete understanding of the system. Checked exceptions catch a lot of normal programming errors and result in more error cases being handled correctly. Like any other restriction imposed by a programming language, they don't ensure perfect code, sometimes they result in busy work, and crappy programmers will find crappy ways to work around them, but IMHO they are helpful for most programmers.
I agree completely with the spirit of this article.<p>Eric Lippert also provides an interesting view of the varieties of exceptions:
<a href="http://blogs.msdn.com/ericlippert/archive/2008/09/10/vexing-exceptions.aspx" rel="nofollow">http://blogs.msdn.com/ericlippert/archive/2008/09/10/vexing-...</a><p>If you follow the philosophy of this article and classify exception's as Eric suggests, you should be in pretty good shape.
> Use finally to stabilize program state when exceptions are thrown
> Catch and handle exceptions locally when the effects of the error are local and completely understood
> Wrap independent units of work in try-catch blocks to handle errors that have global impact<p>... isn't this what everybody does?