[brabel]

People are now realizing that having the errors a function can cause right in the type system may actually have been a good idea, but when you point out that Result is not the only way and that Java checked Exceptions do the exact same thing (and so does the Zig error handling mechanism which is a third variant of the idea), they come up with all sorts of easily dismissable nonsense to explain why the two are very different.

[oblio]

What would you reply to this comment:

https://news.ycombinator.com/item?id=37174698

[brabel]

Well, that's kind of true! The fact checked Exceptions are inconvenient doesn't change the fact they are equivalent to returning a Result type (the implementation is obviously different but I think we don't need to mention that).

A future version of Java could totally make it more convenient, and perhaps even make the implementation cheaper such that it would not just nearly the same , but literally the same as in Rust or other similar languages.

[piaste]

Does it even need a new language version? If the compiler already spits out the error "hey, your Fart() function should be annotated with 'throws ButtsException'", couldn't an IDE relatively easily be configured to automatically add the " throws " annotations?

[brabel]

Have you ever used Java?? Any half decent IDE has done that since 2000.

[piaste]

Never in anger - I've done some JVM coding, but always in Kotlin (which doesn't have checked exceptions).

If Java IDEs have been able to automatically take care of checked exceptions forever, then why do people say that they're inconvenient?

[brabel]

Because the people saying that usually do not program in Java.

[layer8]

I’m not the parent, but exception declarations are IMO necessary for a stable API contract. It’s exactly the same reason why return types are explicit. The actual issue in Java is that you can’t abstract over an arbitrary-length list (sum) of checked-exception types (variadic type parameters) (with the exception of rethrowing from multi-catch clauses).