Checked Exceptions and Unchecked Exceptions
Errors do happen in a computer program. Generally speaking, there are two kinds of possible errors
in a program. One kind happens due to problems originating from the execution environment,
such as running out of memory, and is represented in Java by the class Error and its subclasses.
The second kind of error, called an exception, happens due to problems originating inside the
application itself, and is represented by the class Exception and its subclasses. When an exception
happens, either there is code to handle it or it is ignored. If it is ignored, the program terminates.
However, Java offers an extensive mechanism to handle exceptions. When an exception happens,
the exception propagates, changing the normal execution control flow of the application. In other
words, exceptions are the messengers that carry the bad news inside the world of an application.
Programmers may use the exception-handling mechanism of Java to write well-behaved, robust
Java applications.
Checked Exceptions:
This is the category of exceptions for which the compiler checks (hence the name checked exceptions)
to ensure that your code is prepared for them: prepare for unwelcome but expected guests.
These exceptions are the instances of the Exception class or one of its subclasses, excluding the
RuntimeException subtree. Checked exceptions are generally related to how the program interacts
with its environment; for example, URISyntaxException and ClassNotFoundException are checked
exceptions.
The conditions that generate checked exceptions are generally outside the control of your program,
and hence they can occur in a correct program. However, you can anticipate (expect) them,
and thus you must write the code to deal with them. The rule is: when a checked exception is
expected, either declare it in the throws clause of your method or catch it in the body of your
method, or do both; i.e. you can just throw it without catching it, you can catch it and recover from
it, or you can catch it and rethrow it after doing something with it. Just throwing it without catching
it is also called ducking it.
The programmer is required to write code to deal with checked exceptions. The compiler checks that
such code exists. Dealing with (or handling) an exception means either declaring it in the throws clause of your
method or catching it inside the method, or both.
Runtime Exceptions:
The exceptions of type RuntimeException occur due to program bugs. The programmer is not
required to provide code for these exceptions because if the programming were done correctly in
the first place, these exceptions wouldn’t occur, anyway. Because a runtime exception occurs as a
result of incorrect code, catching the exception at runtime is not going to help, although doing so is
not illegal. However, you would rather write the correct code to avoid the runtime exceptions than
write the code to catch them. An exception represented by the ArithmeticException class is an
example of runtime exceptions. Again, you do not need to declare or catch these exceptions.
Runtime exceptions (exceptions of type RuntimeException or its subclasses) and errors (of type
Error or its subclasses) combined are also called unchecked exceptions and they are mostly thrown
by the JVM, whereas the checked exceptions are mostly thrown programmatically. However, there is
no rigid rule.
Examples of Runtime Exceptions are: ArrayIndexOutOfBounds Exceptions , ClassCast Exception, IllegarArugumentException, IllegalStateException, NullPointerException, NumberFormatException.
These are the unchecked exceptions, which are typically thrown by the JVM or programmatically,
as shown in the table. Remember, it is not illegal to write code for handling unchecked
exceptions, but it will not be of much use. However, you are required to write code for handling
checked exceptions.
References: scjp
in a program. One kind happens due to problems originating from the execution environment,
such as running out of memory, and is represented in Java by the class Error and its subclasses.
The second kind of error, called an exception, happens due to problems originating inside the
application itself, and is represented by the class Exception and its subclasses. When an exception
happens, either there is code to handle it or it is ignored. If it is ignored, the program terminates.
However, Java offers an extensive mechanism to handle exceptions. When an exception happens,
the exception propagates, changing the normal execution control flow of the application. In other
words, exceptions are the messengers that carry the bad news inside the world of an application.
Programmers may use the exception-handling mechanism of Java to write well-behaved, robust
Java applications.
Checked Exceptions:
This is the category of exceptions for which the compiler checks (hence the name checked exceptions)
to ensure that your code is prepared for them: prepare for unwelcome but expected guests.
These exceptions are the instances of the Exception class or one of its subclasses, excluding the
RuntimeException subtree. Checked exceptions are generally related to how the program interacts
with its environment; for example, URISyntaxException and ClassNotFoundException are checked
exceptions.
The conditions that generate checked exceptions are generally outside the control of your program,
and hence they can occur in a correct program. However, you can anticipate (expect) them,
and thus you must write the code to deal with them. The rule is: when a checked exception is
expected, either declare it in the throws clause of your method or catch it in the body of your
method, or do both; i.e. you can just throw it without catching it, you can catch it and recover from
it, or you can catch it and rethrow it after doing something with it. Just throwing it without catching
it is also called ducking it.
The programmer is required to write code to deal with checked exceptions. The compiler checks that
such code exists. Dealing with (or handling) an exception means either declaring it in the throws clause of your
method or catching it inside the method, or both.
Runtime Exceptions:
The exceptions of type RuntimeException occur due to program bugs. The programmer is not
required to provide code for these exceptions because if the programming were done correctly in
the first place, these exceptions wouldn’t occur, anyway. Because a runtime exception occurs as a
result of incorrect code, catching the exception at runtime is not going to help, although doing so is
not illegal. However, you would rather write the correct code to avoid the runtime exceptions than
write the code to catch them. An exception represented by the ArithmeticException class is an
example of runtime exceptions. Again, you do not need to declare or catch these exceptions.
Runtime exceptions (exceptions of type RuntimeException or its subclasses) and errors (of type
Error or its subclasses) combined are also called unchecked exceptions and they are mostly thrown
by the JVM, whereas the checked exceptions are mostly thrown programmatically. However, there is
no rigid rule.
Examples of Runtime Exceptions are: ArrayIndexOutOfBounds Exceptions , ClassCast Exception, IllegarArugumentException, IllegalStateException, NullPointerException, NumberFormatException.
These are the unchecked exceptions, which are typically thrown by the JVM or programmatically,
as shown in the table. Remember, it is not illegal to write code for handling unchecked
exceptions, but it will not be of much use. However, you are required to write code for handling
checked exceptions.
References: scjp
