# Java Programming/Checked Exceptions

* Navigate Exceptions topic:( v • d • e )
* Throwing and catching exceptions
* Checked exceptions
* Unchecked exceptions
* Preventing NullPointerException
* Stack trace
* Nesting exceptions (chained exceptions)
A checked exception is a type of exception that must be either caught or declared in the method in which it is thrown. For example, the java.io.IOException is a checked exception. To understand what a checked exception is, consider the following code:
* Code section 6.9: Unhandled exception.
* public void ioOperation(boolean isResourceAvailable) {
* if (!isResourceAvailable) {
* throw new IOException;
This code won't compile because it can throw a checked exception. The compilation error can be resolved in either of two ways: By catching the exception and handling it, or by declaring that the exception can be thrown using the throws keyword.
* Code section 6.10: Catching an exception.
* public void ioOperation(boolean isResourceAvailable) {
* try {
* if (!isResourceAvailable) {
* throw new IOException;
* } catch(IOException e) {
* // Handle caught exceptions.
* Code section 6.11: Declaring an exception.
* public void ioOperation(boolean isResourceAvailable) throws IOException {
* if (!isResourceAvailable) {
* throw new IOException;
In the Java class hierarchy, an exception is a checked exception if it inherits from java.lang.Throwable, but not from java.lang.RuntimeException or java.lang.Error. All the application or business logic exceptions should be checked exceptions.
It is possible that a method declares that it can throw an exception, but actually it does not. Still, the caller has to deal with it. The checked exception declaration has a domino effect. Any methods that will use the previous method will also have to handle the checked exception, and so on.
So the compiler for the Java programming language checks, at compile time, that a program contains handlers for all application exceptions, by analyzing each method body. If, by executing the method body, an exception can be thrown to the caller, that exception must be declared. How does the compiler know whether a method body can throw an exception? That is easy. Inside the method body, there are calls to other methods; the compiler looks at each of their method signature, what exceptions they declared to throw.

## Why Force Exception Handling?

This may look boring to the developer but it forces them to think about all the checked exceptions and increase the code quality. This compile-time checking for the presence of exception handlers is designed to make the application developer life easier. To debug whether a particular thrown exception has a matching catch would be a long process. In conventional languages like C, and C++, a separate error handling debugging were needed. In Java we can be sure that when an application exception is thrown, that exception somewhere in the program is handled. In C, and C++, that has to be tested. In Java that does not need to be tested, so the freed up time can be used for more meaningful testing, testing the business features.

## What Exceptions can be Declared when Overriding a Method?

The checked exception classes specified after the throws keyword are part of the contract between the implementer and user. An overriding method can declare the same exceptions, subclasses or no exceptions.

## What Exceptions can be Declared when Implementing an Interface?

JAVA 1.8 onwards: When interfaces are involved, the implementation declaration may skip a throws-clause but if one wish to have then should be compatible with the interface declarations. In other words, the implementation should throw the declared exception or it's sub-type or no exception.
Prior to Java 1.8: The implementer must declare same exception or its subclass.