What are Checked Exceptions?
- Exceptions that are sub class of java.lang.Exception or java.lang.Throwable are considered to be checked exceptions.
- Such exceptions must either be handled by try-catch or thrown further using throws clause. Otherwise compiler checks & reports compilation problem.
- Most general use or functional related exceptions which can be handled with code & recovered gracefully like show error message to user & ask to try later or try different thing or take alternative flow etc. fall under this category.
What are unchecked / runtime exceptions?
- Exceptions that are sub class of java.lang.RuntimeException or java.lang.Error are considered to be unchecked exceptions.
- Compiler does not expect these exceptions to be handled or thrown.
- Developers may choose to handle these on need basis, but generally this is not recommended.
- Exceptions which can not be handled programatically falls under this category. Such exceptions generally calls for code change or JVM level repair.
Why IOException is a checked / non-runtime exception even though io related exceptions are identified at runtime?
- IOException sounds like a run time exception because they happen during running of application.
- But this occurs due to external factors & code or JVM might not be at fault. This might not need code change but might just need handling like showing or logging error.
- A different valid file can be tried & same code can work just fine which is considered a recovery.
Why java.io.UncheckedIOException wraps a checked java.io.IOException & make it unchecked?
- java.io.UncheckedIOException is newly introduced in Java 8 which wraps java.io.IOException inside it.
- This is used in java.nio.file.Files which provides methods to deal with streams which are helpful in lambdas.
- As per general opinion in online community, having checked exception in lambdas or streams make code unpleasant & goes against lambda purpose, hence this was done. One good reference for this https://dzone.com/articles/how-to-handle-checked-exception-in-lambda-expressi
Why ArithmeticException is a RuntimeException / unchecked exception?
- General use case is divide by zero which sounds like a recoverable exception.
- As per online discussions – All division operations will need to be wrapped in try-catch if this is done which might be unwanted clutter.
- I think, divide by zero condition should be handled gracefully before it happens rather than catching & handling ArithmeticException. So being unchecked seems justified.
- If I think more about this. in my opinion, ArithmeticException is also thrown for cases like overflow of integer in addition (Example java.lang.Math.addExact) which is programmatic or coding issue. This might call for data type change in code to take care of overflow gracefully. API documentation of java.lang.Math seems to agree with this
The best practice is to choose the primitive type and algorithm to avoid overflow. In cases where the size is
longand overflow errors need to be detected, the methods
ArithmeticExceptionwhen the results overflow.
Why IllegalClassFormatException is a checked exception even though sounds like non-recoverable?
- This exception sounds like non-recoverable since it is saying that class format itself is illegal.
- Actually this exception is thrown in ClassFileTransformer.transform which is a instrumentation API i.e. API that modifies classes itself. So if exception occurs in this, then instrumentation code can handle it.
Should we catch RuntimeException / Unchecked exception?
- Here is the answer from horse’s mouth itself i.e from Oracle. Reference
Runtime exceptions can occur anywhere in a program, and in a typical one they can be very numerous. Having to add runtime exceptions in every method declaration would reduce a program’s clarity. Thus, the compiler does not require that you catch or specify runtime exceptions (although you can).
Can we make all exceptions in our application RuntimeException / Unchecked exception? How to choose between checked & unchecked exception in design?
- Again, this is highly opposed clearly by Oracle. Here is documentation by Oracle on Unchecked Exceptions — The Controversy
Here’s the bottom line guideline: If a client can reasonably be expected to recover from an exception, make it a checked exception. If a client cannot do anything to recover from the exception, make it an unchecked exception.