News for hackers. Stuff that matters.
Re:Rating 26 years of Java changes by JavierFlores09 on Saturday October 11, 2025 @06:02PM (#45553063)
Stuart Marks and Nicolai Parlog recently had a discussion about checked exceptions in the Java channel [0]. In short, while they mentioned that there are certainly some things to improve about checked exceptions, like the confusing hierarchy as well as the boilerplate-y way of handling them, they're not necessarily a failed concept. I do hope they get to work on them in the near future.

0: https://www.youtube.com/watch?v=lnfnF7otEnk

Re:Rating 26 years of Java changes by vbezhenar on Saturday October 11, 2025 @06:26PM (#45553189)
They are absolutely failed concept in Java. Every first popular library uses unchecked exceptions, including famous Spring. Java streams API does not support checked exceptions. Even Java standard library nowadays includes "UncheckedIOException". Kotlin, Scala: both languages grown from JVM and do not support checked exceptions.
Re:Rating 26 years of Java changes by samus on Sunday October 12, 2025 @02:21AM (#45555754)
Spring has a special error handling strategy where the whole request is allowed to fail, punting error handling off to the caller.

A lot of code that throws checked exceptions is simply dangerous to use with Java streams because the execution order of stream operation is not obvious and possibly non-deterministic. For this reason, streams were never intended to also handle errors. Reactive frameworks are much better at that.

The UncheckedIOException is for situations where you really cannot throw a checked exceptions, such as inside an iterator. Which might lead to ugly surprises for the API user;

Re:Rating 26 years of Java changes by vbezhenar on Sunday October 12, 2025 @05:48AM (#45556856)
> A lot of code that throws checked exceptions is simply dangerous to use with Java streams because the execution order of stream operation is not obvious and possibly non-deterministic.

From the type system PoV, they could have just written something like `interface Runnable<X> { void run() throws X; }` and now `forEach` would have been written like `<X> void forEach(Runnable<X> r) throws X`. And repeat that for all stream operations, promoting `X` everywhere, so if your mapper function throws SQLException, the whole pipeline will throw it.

It even works today with some limitation (there's no way for `X` to get value of `SQLException|IOException` union type), but with some generic improvements it could work.

But they decided to not touch this issue at all. So now people will fool compiler with their tricks to throw checked exceptions like unchecked (or just wrap them with UncheckedXxxException everywhere, I prefer that approach).

Re:Rating 26 years of Java changes by samus on Monday October 13, 2025 @07:54AM (#45567342)
At the risk of repeating myself: streams were simply never designed with error handling in mind. Aborting everything at the first error is just the most simplistic error handling strategy. Reactive streams frameworks should be preferred for this.
Re:Rating 26 years of Java changes by peterashford on Sunday October 12, 2025 @08:33PM (#45563488)
I agree. The only issue for me is that they could be less verbose but given that I'm always using an IDE, this is in practice a non-issue