As a professional Java programmer, with some experience in various strongly typed languages (MLs, Haskell), I really liked the idea of Checked Exceptions when I

As a professional Java programmer, with some experience in various strongly typed languages (MLs, Haskell), I really liked the idea of Checked Exceptions when I first heard about them (and even when I used them in small projects in school). In principle, it seems like a way to allow for stronger static analysis and allows the compiler to make stronger safety guarantees. It also forces programmers to deal with oddball cases - instead of just ignoring them like we are prone to do with magic return values (a la C) or unchecked exceptions. The problem is it never works. There are two common strategies that I've encountered to deal with 90+% of checked exceptions: -Most code just bubbles the exceptions up the top layer (i.e., the UI), which clutters up every method signature along the way. The UI then has a big handler that catches all exceptions, and just logs an error and shuts down the program. Even on the off chance that the top-level could do something more productive, the problem is that the stack has been unwound too far and it's too late to fix whatever the problem is. -The other common approach is to wrap every checked exception inside a custom unchecked exception that is just thrown. This is my preferred solution (at least it doesn't clutter up every method signature), but I have to explicitly convert every checked exception into an unchecked one - which is just a bit of a hassle. I give Sun some props for trying out on a limb with a really cool sounding idea. But I think most people have realized it doesn't work very well in practice ...