Yes, you are absolutely right. They sound like a great idea, but it seems like "throws Exception" is something that gets tacked onto any method with side effects. It's just not easy to write imperative programs without throwing exceptions somewhere along the call chain.

(Another thing that could have gone this way are parameterized types representing null/not-null, like Haskell's Maybe or Either. It seems like a lot of work to annotate every type that can possibly be null, but it is not onerous at all in real life. A few functions are Maybe/Either, but most aren't; and for the price of an annotation you can be sure that you will never get a "NullPointerException". Checked exceptions could have turned out this way, but something about Java, Java's libraries, or imperative programming in general made this not so.)

> It's just not easy to write imperative programs without throwing exceptions somewhere along the call chain

With checked exceptions it is also not easy to be a good OOP citizen and not break encapsulation, since checked exceptions become a part of your interface.