I started to use Java Records with the Binder and noticed that writeRecord is throwing a ValdidationException and this is a checked exception that I have to handle.
I didn’t notice that so far because with classes I use writeBeanIfValid and this returns a boolean.
What was the reason to use checked exceptions?
In case of writeBean method it is sort of obvious, as it is “public void writeBean(BEAN)” by signature. Technically writeRecord could have alternative implementation of just returning null when validations not passing, or use Optional wrapping.
The question was about why ValidationException is a checked exception and not a RuntimeException.
This forces me to catch the exception.
Yes, because there is no return value. Otherwise you can’t know if the validations passed, so with this method it is mandatory. If you do not like to implement this via catching exception, writeBeanIfValid can be used instead.
Yes I understand but I there is no such method with writeRecord.
My point is: Checked Exceptions are a mistake in the Java design. C# for example doesn’t have checked exceptions.
If I have an exception handler registered and want to catch the exception there I always have to wrap it in a RuntimeException.
We should probably add a similar writeRecordIfValid method as well.
But I disagree that checked exceptions are a universal mistake. As an API designer, there are cases where it makes sense to “force” the user to take the possibility of an “expected” and recoverable error case into account. The other way for doing that for a method that also needs to return a value would be to return some kind of ResultOrError object and have the developer do conditional checking on the value type. This used to be even more inconvenient than checked exceptions before Java got sealed types and type patterns.