[karatinversion]

On top of all the other problems pointed out, java's checked exceptions don't even do a good job of indicating possible failure conditions. The standard library set the tone on this with exception like IOException, which has an enormous amount of subclasses represting different IOExceptions, and is thrown by anything related to IO. So I still need to rely on documenation or code inspection to understand what exceptions might actually be thrown and what they mean, if I want to recover from errors.

The classic case of this is that the compiler cannot tell that

    new StringReader("Example").read()

doesn't throw an SSLException.

[ragnese]

But, you're conflating a language feature "Java's checked exceptions" with bad API design, which is obviously possible with any combination of any language's features. I agree that Java's standard library has a ton of bad APIs--not just the checked exception hierarchies, but that does not necessarily mean that checked exceptions are a bad idea.

Just to put an extremely fine point on it, one thing I always complain about is the JDBC ResultSet API. If I have a SQL database table that has a nullable integer column, and I query that column for a row that happens to have that column set to `NULL`, then the ResultSet API will give me the int value `0` for that column and I have to just know that I need to call `wasNull()` (or whatever it's called) to ask the ResultSet if the last thing it returned was really supposed to be null or not. Yet, the ResultSet API does not make me think that Java shouldn't have `int`, or class methods, or any way to query databases--it only makes me think that the JDBC API is really, really, poor.

[nine_k]

The question was, why checked exceptions saw no love. A big part of the answer is that the stdlib did a very poor job showcasing them.

No wonder, it was an attempt to graft an FP-esque feature onto a deeply imperative OOP language, with a development team aligned with OOP concepts. I suspect the stdlib team lacked either the understanding or the means to make the use of e.g. IOException nicer. They didn't even have type parameters at their disposal yet. It was botched as a result, and deprecated.

It's an interesting mental exercise to try and design a better implementation of the idea within the constraints of Java. (Implementing the monadic approach is likely the easiest and cleanest way.)

[ragnese]

> The question was, why checked exceptions saw no love. A big part of the answer is that the stdlib did a very poor job showcasing them.

Fair enough. I can see that interpretation. I was more focused on their first sentence, which said: "On top of all the other problems pointed out, java's checked exceptions don't even do a good job of indicating possible failure conditions." Then it felt like they were backing that claim by citing a specific example that's just a poor use of the feature.

> No wonder, it was an attempt to graft an FP-esque feature onto a deeply imperative OOP language, with a development team aligned with OOP concepts.

That's an interesting take that I hadn't really heard before or considered myself. I had assumed that it came from some frustration around C++ exceptions and not knowing what was supposed to be handled vs not.

But, in any case, I do agree that the feature ended up rejected by the larger programming community largely because of Java's specific implementation of it.

Though, I have to say that I think it might have ended up rejected even if Java did a perfect job of it in the standard library. The truth is that most programmers don't seem to understand the intended design of the feature and feel like there's a binary choice between using checked exceptions or unchecked exceptions. The Oracle documentation does a very good job, IMO, of explaining the feature, how it's intended to be used, and how do decide whether to use an unchecked exception or a checked one. But, I don't think most people actually read manuals/books to learn programming languages anymore.