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.
Answer from Bozho on Stack OverflowMany 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.
Checked vs Unchecked Exceptions in Java - Stack Overflow
Checked vs unchecked
Why are checked exceptions frowned upon?
Some thoughts: The real problem with checked exceptions
Videos
A checked exception required a throw clause on the method header but not for the unchecked exception?
What is the difference between the two? How do I know if it is unchecked vs checked?
CheckedException needs to be handled by the caller, Unchecked exception don't.
So, when you design your application you should take in mind what kind of exceptional situation you are managing.
For example, if you design a validation method that checks the validity of some user input, then you know that the caller must check the validation exception and display the errors to the user in a nice looking way. This should be a checked exception.
Or, for those exceptional conditions that can be recovered: imagine you have a load balancer and you want notify the caller that one of the "n" servers is down, so the caller must recover the incident re-routing the message to another server; this should be a checked exception, because it is crucial that the caller (client) tries to recover the error, and don't just let the error to break the program flow.
Instead, there are many conditions that should not happen, and/or should instead break the program. For example, a programming error (like division by zero, null pointer exception), a wrong usage of an API (IllegalStateException, OperationNotSupportedException), an hardware crash, or just some minor situation that are not recoverable (lost connection to a server), or a doomsday :-) ; in those cases, the normal handling is to let the exception reach the most outer block of your code that displays to the user that an unpredictable error has occurred and the application can't do nothing to continue. It's a a fatal condition, so the only thing you can do is to print it to the logs or showing it to the user in the user interface. In those cases, catching the exception is wrong, because, after catching the exception you need to manually stop the program to avoid further damages; so it could be better to let some kind of exception "hit the fan" :)
For those reasons there are some exceptions that are Unchecked also in the JRE: OutOfMemoryError (unrecoverable), NullPointerException (it's a bug that needs to be fixed), ArrayIndexOutOfBoundsException (another bug example), and so on.
I personally think that also SQLException should be unchecked, since it denotes a bug in the program, or a connection problem to the database. But there are many examples where you get exception that you really don't have any clue in how to manage (RemoteException).
The best way to handle exceptions are: if you can recover or manage the exception, handle it. Otherwise let the exception pass out; somebody else will need to handle. If you are the last "somebody else" and you don't know how to handle an exception, just display it (log or display in the UI).
- you do not need to declare unchecked exceptions in a
throwsclause; but you must declare checked exceptions; RuntimeExceptionandError, and all of their subclasses (IllegalArgumentException,StackOverflowErroretc), are unckecked exceptions; the fact thatRuntimeExceptionis unchecked, unlike otherThrowablesubclasses, is by design;- there is no such thing as "compile time exceptions".
More generally, it is considered that unchecked exceptions are thrown in the event of either JVM errors or programmer errors. One famous such exception is NullPointerException, often abbreviated as NPE, which is a subclass of RuntimeException, and therefore unchecked.
Another very crucial difference between unchecked exceptions and checked exceptions is that within a try-catch block, if you want to catch unchecked exceptions, you must catch them explicitly.
Final note: if you have exception classes E1 and E2 and E2 extends E1, then catching and/or throwing E1 also catches/throws E2. This stands for both checked and unchecked exceptions. This has an implication on catch blocks: if you do differentiate between catching E2 and E1, you must catch E2 first.
For instance:
// IllegalArgumentException is unchecked, no need to declare it
public void illegal()
{
throw new IllegalArgumentException("meh");
}
// IOException is a checked exception, it must be declared
public void ioerror()
throws IOException
{
throw new IOException("meh");
}
// Sample code using illegal(): if you want to catch IllegalArgumentException,
// you must do so explicitly. Not catching it is not considered an error
public void f()
{
try {
illegal();
} catch (IllegalArgumentException e) { // Explicit catch!
doSomething();
}
}
I hope this makes things clearer...