But not quite ...

So what went wrong with checked exceptions? Well, they try to force a programmer to think about something that they don't want to, and prevent them from thinking about what they do want to.

So they turn them off, swallowing exceptions left and right. Just letting an exception propagate is much better than swallowing all the time. So what happens is that Checked Exceptions become just as important in an API design as the method name, return type or parameter list as far as the compiler is concerned, but from the point of view of the API designer or the programmer, they are just not very important and tend to be forgotten, causing pain in the API.

Ironically, it is precisely Java where this is a problem. Java is a language of corporate development. Corporate development doesn't generally involve a great amount of thinking about such high level robustness, so a typical Java developer is all the more likely to look at their code and say: "It compiles, it runs, looks good." and not think about error scenarios. It litterally never occurs to them.

Of course not all Java developers, but enough that it matters.

So I think the correct balance in such a language is to have compiler warnings. Let the compiler tag classes that can throw checked exceptions, and if you fail to deal with them explicitly (throws or catch) then it will generate a compiler warning. You either care about that or you don't, but you are not swallowing exceptions.