You might want to read what Bruce Eckel has to say about checked exceptions. The short version: checked exceptions sound better than they actually are.

In my experience, having a robust test suite is a great way to go. If a programmer misses something, write a test to verify the bug by watching the test fail, fix the bug, rerun the test and make sure it passes. Gradually over time, you can build a nice test suite which is going to cover the problems you face.

With checked exceptions, a programmer who's under the gun might stub out some exception handling code and then later forget to flesh it out. It's a natural problem, but checked exceptions can lull you into the false belief that you're really handling those issues.

For other readers unclear on this: think of a checked exception as something that can fail forcing you to wrap it in an eval at compile time and then testing the result:

eval {$some->method};
if ($@) {};
[download]

If you were forced to do that at compile time, you might see a lot of stubbed out error checking like I demonstrated. In Java, it's something like this:

try {
    some.method();
} 
catch (DealWithThisExceptionLater e) {}
[download]

Personally, I'd feel much more comfortable with a nice test suite that I can build on rather than littering the actual code with stuff that I might never need.