[flipp3r]

..wat. Either rethrow it, deal with it, or rethrow it as unchecked. As a Java developer, you can make the choice. I really don't have any issues with libraries telling me something can go wrong. I'd rather know something can go wrong before putting my code in production than while it runs.

[wtetzner]

I think the real problem is that the "rethrow as unchecked" case is probably the most common, but is clunky and verbose.

A more ergonomic way to do that would probably make people stop complaining so much.

This problem is especially noticeable when using lambdas. If you're implementing an interface that doesn't have a throws clause, but the body calls something that throws a checked exception, you _have_ to introduce a try/catch to your lambda body. You don't get to re-throw it without wrapping it in a RuntimeException.

[pjmlp]

Not only that, the idea of checked exceptions actually appeared on CLU, Modula-3 and C++ before Java came into scene, but somehow only Java gets mentioned.

Nowadays I spend most of my time on other languages and while it is more ergonomic, I do spend more time reading documentation regarding possible errors.

[vbezhenar]

There are no checked exceptions in C++. throws in C++ is very different from Java, even if syntax is similar.

[josefx]

You could declare throw() exceptions in C++. If you did that the runtime would intercept and typecheck any thrown exception against that list. Calling code could rely on that list since any not listed exception would cause the application to terminate. Modern C++ replaced that with noexcept - a function either can throw or it can't and template code can branch on that information.

[pjmlp]

Yes there are.

Just that instead of being a compiler error like in Java, the unexpected() handler is called; which by default calls terminate() to kill the application.

This behaviour has been removed in C++17.

However C++23 might introduce a similar syntax for value type exceptions, but following up semantics similar to how Swift does it.