Exactly. I think the 2 key failings of the checked exception idea (there are others, but not as important) are 1) Precise exception specifications leak impleme

Exactly. I think the 2 key failings of the checked exception idea (there are others, but not as important) are 1) Precise exception specifications leak implementation details. This will bite you badly, e.g., when you want to change the implementation from under a published API. 2) The times when we only care that some exception occurred vastly outnumber the times when we care about the exact types of exceptions that may occur. Checked exceptions don't add any value to the common case, in fact they make it worse, because generic exception handlers tend to live many levels up the call stack from where exceptions are thrown(1), and therefore they "aggregate" large amounts of code that that can collectively throw a huge range of exceptions. If you were to carry around detailed "throws" clauses, they would be a mile long. The funny thing is, all solutions that solve the problems created by checked exceptions do so by subverting the mechanism one way or another. So you're better off without checked exceptions in the first place. I've always been interested in this discussion because it's one of those cases where an idea seems very good on paper, only to turn out quite bad in practice. (1) This observation is what makes exceptions such a useful mechanism in the first place.