

You must be logged to download. Click here to login




No, I'd like to download without make the donation




No, I'd like to download without make the donation

Checked versus Unchecked Exceptions in Java

See in this article a complete overview around how to deal with checked and unchecked exceptions in Java.

It is remarkable the large number of programmers and developers who do not know how to handle exceptions that occur in the applications that they develop, whether the scope is desktop, web or mobile. In this scenario, many questions come up, such as: "Where should I implement the exception?" Or "What kind it should be?" Or "Should I handle it or throw it?" Questions like these that show us how developers from various programming languages need to better understand how these same languages deal with handling native exceptions, as well as understand the patterns and concepts that the community consider as "approved" and functional.

In the case of Java, specifically, the more we go down the detail level of technology, the more we encounter issues like hierarchy of exceptions, forms of treatment for the various versions of the language, as well as the old differences between the checked and unchecked exceptions, the subject of this article. Numerous articles and forums on the web deal with the subject in various contexts and business scenarios. In this article, we will try to represent some of the key questions about this difference through examples and explanations.

If you want to complement your knowledge regarding Exceptions in Java, please refer to some of our other articles in the portal:


The main difference between a checked exception and an unchecked exception is that the first requires the developer to treat it. That is, using one of two basic forms of exception handling in Java: capture or treatment; while the second exception does not. Treatment, in the case of unchecked exceptions becomes optional and you treat only if you want.

Another way of looking at this difference is to think you use a checked exception every time you know that it will happen. What does that mean? It's simple; if in your Java method you feel that a particular error will occur and you need to point it to other layers or treat it in the same place, then you will have, without a doubt, a case of checked exception. See Listing 1, for an example. It is observed that the objective of the code is to launch an exception to be treated for other classes that call the method in question, since you know the cause of the error and know that it will happen.

Listing 1. Example of a checked exception

public double calculateBMI(double height, double weight) throws IMCException {
 double IMC = (weight)/(height*height);
 if (IMC <= 18.5) {
    throw new IMCException(“Underweight!”);
 // Rest of the code...

This type of situation "forces" the throwing/treatment of the exception and differs from situations where we know that the error will happen. But how do we know that the error "will not happen ..."? It is also simple: when it happens at runtime.

To understand this, you must first understand how the exceptions hierarchy works. See Figure 1.

Figure 1. Checked and unchecked exception model

In blue we have cases of checked exceptions, where the use of any method anywhere in the Java API that has mapped these exceptions will be forced to treat/capture the same. Exceptions present in operations are the ones that pose a risk to the application, as exceptions to access files or IO devices (Input/Output) - IOException.java, database access -SQLException.java or classes not found exceptions - ClassNotFoundException.java. These exceptions inherit directly from java.lang.Exception, parent class of all exceptions in Java.

As for the exceptions of unchecked type have direct hierarchy with RuntimeException (which in turn inherits from Exception). This means that what qualifies an exception as unchecked is that it directly inherit from this class and not from Exception, as we have in checked ones.

Probably, you have already been asked to implement several times SQLException kind of exceptions when you were working with the database and not even noticed that you were in fact forced to. At the same time, it is more than certain that you have already seendozens of NullPointerException type exceptions in the console of your IDE while the application was being debugged or executed. In this case in particular, we cannot know when a NullPointerException will happen, since we only have this scenario when values are being manipulated at runtime.

In short, we can list the differences in a list of points to consider:

1 - Checked Exceptions

  • Represent invalid conditions in areas outside the immediate control of the program (the invalid user input problems, database, network failures, missing files);
  • Are subclasses of Exception;
  • A method is required to establish a policy for all checked exceptions thrown by its implementation (or pass the checked exception higher up the stack, or manipulate it in some way).

2 - Unchecked Exceptions

  • Represent faults in the program (bugs) - often invalid arguments passed to a non-private method. In the book "The Java Programming Language" by Gosling, Arnold, and Holmes, we have "unchecked run-time exceptions represent conditions that generally reflect errors in the logic of your program and cannot reasonably be recovered in execution time.";
  • They are subclasses of RuntimeException, and are usually implemented using IllegalArgumentException, NullPointerException, or IllegalStateException;
  • A method is not required to establish a policy for unchecked exceptions thrown by its execution (and often do not).

To illustrate one unchecked exception there is no better class than a utilitarian. The utility classes are filled of unchecked exceptions within the Java API. See in Listing 2 some methods that exemplify that, based on the summing up we've done.

Listing 2. Example of utility class with unchecked exceptions.

public final class Utilitarios {  
   public static void checkContent(String text){
       throw new IllegalArgumentException("text does not have visible content!");
   public static void checkInterval(int number, int minor, int major) {
     if (!Util.isInTheInterval(number, minor, major)) {
       throw new IllegalArgumentException(number + " isn't into the interval" + minor + ".." + major);
   public static void checarForMore(int number) {
     if (number < 1) {
       throw new IllegalArgumentException(number + " is less than 1.");
   public static void checkForMatch(Pattern pattern, String text){
     if (!Util.marcar(pattern, text)) {
       throw new IllegalArgumentException(
         "text " + Util.quote(text) + " does not match '" + pattern.pattern() + "'"
   public static void checarForNull(Object object) {
     if (object == null) {
       throw new NullPointerException();

Where to use them?

This question disturbs the minds of many programmers, especially when they are new or have limited time experience in the language.

This same user started his speech with a quote from "Effective Java" book which is worth reading:

"Use checked exceptions to recover the conditions and runtime exceptions for programming errors (item 58 in 2nd edition)".

Below are the five issues raised and their answers:

1. The code below can be considered a checked exception?

try {
     String input = // read in user input
     Long id = Long.parseLong(input);
 } catch(NumberFormatException e) {
     id = 0; // rule for id = 0

2. RuntimeException is an unchecked exception?

try {
     File file = new File("path");
     FileInputStream fis = new FileInputStream(file);   
 } catch(FileNotFoundException e) {

3. What should I do here?

   // Should I throw a "throw new FileNotFoundException("File not found");"?
    // Should I log?
    // Or simply use a System.exit(0);?

4. The code below should be a checked exception? Can I recover the situation like this?

     String filePath = …
     File file = new File(filePath);
     FileInputStream fis = new FileInputStream(file);   
 } catch(FileNotFoundException e) {
     // Please, ask the user an error message
     // Ask user to get back to file path.

5. Why shall we do this?

public void someMethod throws Exception{

See the answers:

  1. No. NumberFormatException is unchecked (= is a RuntimeException subclass).
  2. Yes, exactly.
  3. It depends on where this code is and what you want to happen. If the UI layer - pick it up and display a warning if it is in the service layer - do not get it at all - let it flow. Just do not swallow the exception. If an exception occurs in most cases, you should choose one of these:
    • register it and return;
    • re-throw it (declare it to be threw by the method);
    • build a new exception, passing the current in the constructor.
  4. Could have been. But nothing prevents you from taking the unchecked exception.
  5. Most of the time - because people are lazy to consider what to get and what to re-throw. Throwing an exception is a bad practice and should be avoided.




Web developer and passioned for web design, SEO and front end technologies.

What did you think of this post?

  See the prices for this post in Mr.Bool Credits System below:




> More info about MrBool Credits
You must be logged to download.

Click here to login