Videos
Many a blog post has been written about how Checked Exception are bad/the devil incarnate.
For all the bloviating about how bad it is, most of these articles and their comment sections lack any concrete alternatives.
For Java versions before 21, there simply doesn't seem to be a reasonable (never mind close to standardized) alternative to express that a method returns Thing or AException or BException.
For Java 21+, with sealed classes and exhaustive switches, you kind of can manually recreate a vague resemblance of e.g. Rusts Result Type. That will still lack some necessities, like enforcing checking the Error for Void methods (as in Result<Void, Err>).
So my question is:
If you agree that checked exceptions are bad, what alternative are you actively using right now?
How is your favorite library handling this? Because most still seem to use exceptions
Personally, I'm getting reaaaallly annoyed by the way people talk about exceptions online. For one, they'll point out a problem, but then fail to demonstrate a solution that wouldn't have it. For another, there's very little will, it seems, to suggest and work towards a serious alternative. How can we, as a community, warn against using a builtin feature for an important part of programming without providing alternatives? Aren't we simply screwing over newbies with these takes?
Many people say that checked exceptions (i.e. these that you should explicitly catch or rethrow) should not be used at all. They were eliminated in C# for example, and most languages don't have them. So you can always throw a subclass of RuntimeException (unchecked exception).
However, I think checked exceptions are useful - they are used when you want to force the user of your API to think how to handle the exceptional situation (if it is recoverable). It's just that checked exceptions are overused in the Java platform, which makes people hate them.
Here's my extended view on the topic.
As for the particular questions:
Is the
NumberFormatExceptionconsidered a checked exception?
No.NumberFormatExceptionis unchecked (= is subclass ofRuntimeException). Why? I don't know. (but there should have been a methodisValidInteger(..))Is
RuntimeExceptionan unchecked exception?
Yes, exactly.What should I do here?
It depends on where this code is and what you want to happen. If it is in the UI layer - catch it and show a warning; if it's in the service layer - don't catch it at all - let it bubble. Just don't swallow the exception. If an exception occurs, in most of the cases, you should choose one of these:
- log it and return
- rethrow it (declare it to be thrown by the method)
- construct a new exception by passing the current one in constructor
Now, couldn't the above code also be a checked exception? I can try to recover the situation like this? Can I?
It could've been. But nothing stops you from catching the unchecked exception as well.Why do people add class
Exceptionin the throws clause?
Most often because people are lazy to consider what to catch and what to rethrow. ThrowingExceptionis a bad practice and should be avoided.
Alas, there is no single rule to let you determine when to catch, when to rethrow, when to use checked and when to use unchecked exceptions. I agree this causes much confusion and a lot of bad code. The general principle is stated by Bloch (you quoted a part of it). And the general principle is to rethrow an exception to the layer where you can handle it.
Whether something is a "checked exception" has nothing to do with whether you catch it or what you do in the catch block. It's a property of exception classes. Anything that is a subclass of Exception except for RuntimeException and its subclasses is a checked exception.
The Java compiler forces you to either catch checked exceptions or declare them in the method signature. It was supposed to improve program safety, but the majority opinion seems to be that it's not worth the design problems it creates.
Why do they let the exception bubble up? Isnt handle error the sooner the better? Why bubble up?
Because that's the entire point of exceptions. Without this possibility, you would not need exceptions. They enable you to handle errors at a level you choose, rather than forcing you to deal with them in low-level methods where they originally occur.