Java exceptions: Common terminology with examples [2019 guide]

The Java programming language comes with advanced exception handling features that help programmers manage exceptional events. In Java, exceptions are either thrown by the compiler or occur during the execution of the program. Exceptions stop the normal flow of the program, so you need to handle them appropriately.

In this article, we’ll have a look at all the terms and examples you need to know about Java exceptions in 2018.

What are Java exceptions?

Java exceptions are events that disrupt the normal execution of the program. The main goal of exceptions is to separate error-handling from regular code. Exceptions might stem from a wide range of problems such as missing resources, coding errors, memory errors, and others. In Java, there are two kinds of exceptions:

  1. Unchecked exceptions (runtime exceptions)
  2. Checked exceptions (compile-time exceptions)

1. Unchecked exceptions

Unchecked exceptions are issues that occur at runtime. They are also called uncaught or runtime exceptions. As unchecked exceptions aren’t checked at compile time, you aren’t required to specify or handle the exception (although you can if you want). They are usually the results of bad coding practices or logical errors such as data errors, invalid arguments, or missing resources.

Basic arithmetic errors such as divide by zero are the easiest example of unchecked exceptions. For instance, here’s a code example that throws [ArithmeticException](https://docs.oracle.com/javase/9/docs/api/java/lang/ArithmeticException.html "ArithmeticException") at runtime:

public class ArithmeticException {

	public static void main(String[] args) {

	    int a = 0;
	    int b = 100;
	    int c = b/a;

	    System.out.println("Result: " + c);
	}

}

Of course, divide by zero is an operation that’s impossible to execute. The console output is:

Exception in thread "main" java.lang.ArithmeticException: / by zero
at arithmetic.ArithmeticException.main(ArithmeticException.java:9)

Wanting to access non-existent data is another typical example of unchecked exceptions. Say, you have an array of six elements and try to print out the item at index 10:

public class InvalidArrayIndex {

	public static void main(String[] args) {
		int myArray[] = {0, 1, 2, 3, 4, 5};

		System.out.println(myArray[10]);

	}

}

As there’s nothing at index 10, the above code example throws [ArrayIndexOutOfBoundsException](https://docs.oracle.com/javase/9/docs/api/java/lang/ArrayIndexOutOfBoundsException.html "ArrayIndexOutOfBoundsException"):

Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 10
	at invalidarrayindex.InvalidArrayIndex.main(InvalidArrayIndex.java:8)

There are more complicated examples of unchecked exceptions as well. The most frequent unchecked exception is called [NullPointerException](https://docs.oracle.com/javase/9/docs/api/java/lang/NullPointerException.html "NullPointerException"). It’s also among the top 4 Java exceptionsRaygun users encounter. NullPointerException happens when your app tries to use null where an object is required. This can be caused by different reasons such as accessing an uninitialized variable or calling the instance method of a null object.

2. Checked exceptions

Checked exceptions are also called compile-time exceptions, as they arise at compile time. Java code containing any checked exceptions won’t compile. When you try to run such code, the compiler warns you about the presence of the checked exception. If you still choose to compile the code you’ll encounter the “unresolved compilation problems” message.

[IOException](https://docs.oracle.com/javase/9/docs/api/java/io/IOException.html "IOException") is one of the most common checked exceptions in Java. It’s caused by different input-output problems such as invalid file access or networking errors.

Here’s an example. The following code intends to access a non-existent file, then write something into it:

import java.io.FileWriter;

public class FileNotFound {

   public static void main(String args[]) {		
      FileWriter myWriter = new FileWriter("C://filenotfound.txt");

      myWriter.write("Hi, I'm trying to write something.");
      myWriter.close();
   }
}

Needless to say, it’s not possible to write anything into a file that doesn’t exist. My Eclipse IDE informs me about the presence of IOException and asks if I still want to compile the code.

Remember that the compiler had no complaints in the case of unchecked exceptions, as they will be thrown only at runtime.

If I proceed with the unhandled exception the compiler returns the following error message:

Exception in thread "main" java.lang.Error: Unresolved compilation problems:
	Unhandled exception type IOException
	Unhandled exception type IOException
	Unhandled exception type IOException

	at fileNotFound.FileNotFound.main(FileNotFound.java:8)

To solve the compilation problem, the method in which the checked exception occurs needs to either handle or at least specify it. Before showing how to do that, let’s have a look at Java’s Exception class hierarchy.

3. Exception classes

Exception classes are Java classes that include all checked and unchecked exceptions. The exceptions I mentioned before such as ArithmeticException and IOException are all represented by an exception class. In fact, Java has an extensive hierarchy of parent and child classes that cover most issues that may occur during compilation or at runtime.

The classification of Java exceptions is a bit confusing, however. The [Throwable](https://docs.oracle.com/javase/9/docs/api/java/lang/Throwable.html "Throwable") class is the superclass of all Java exceptions and errors. It has two subclasses, [Error](https://docs.oracle.com/javase/9/docs/api/java/lang/Error.html "Error") and [Exception](https://docs.oracle.com/javase/9/docs/api/java/lang/Exception.html "Exception") but they don’t represent checked and unchecked exceptions. The Exception class has a subclass called [RuntimeException](https://docs.oracle.com/javase/9/docs/api/java/lang/RuntimeException.html "RuntimeException") that contains most unchecked exceptions. All other subclasses of Exceptionare handled as checked exceptions. Besides runtime exceptions, errors also count as unchecked exceptions.

So: - Subclasses of Exception except for the subclasses of RuntimeException are regarded as checked exceptions. - Subclasses of Error and RuntimeException are regarded as unchecked exceptions.

ErrorException, and RuntimeException all have several subclasses. For example, IOException is a subclass of Exception and NullPointerException is a subclass of RuntimeException.

You may have noticed that Java differentiates errors from exceptions.

Why is that so?

In Java, errors indicate abnormal conditions such as stack overflow that applications shouldn’t try to catch. They are mostly caused by the environment, as opposed to exceptions that are caused by the program itself.

Exceptions are caught either at compile time or at runtime. Errors terminate the program for sure and they cannot be handled in any way. However, exceptions can be recovered by certain programming techniques.

4. Handling exceptions

Exception handling in Java happens with the trycatch, and finally blocks. You can use them to define how you want to handle exceptions when they occur. The try block should include the code that may or may not throw an exception. Each catch block is an exception handler that deals with an exception thrown by the try block. The finally block executes in any case, whether an exception has been thrown or not.

You can include as many catch blocks as you want. However, you can add only one finally to each try block. Programmers usually use finally blocks to do the cleanup after the try and catch blocks have been executed.

Here’s the general syntax of Java’s exception handling:

try {

   // Code that might throw exceptions.

} catch (Exception e1) {


   // Catch block 1. Executes if try block throws e1.


} catch (Exception e2) {


   // Catch block 2. Executes if try block throws e2.


} catch (Exception e3) {


   // Catch block 3. Executes if try block throws e3.


} finally {


   // Cleanup code. Always executes.


}

Handling checked exceptions

Here’s how you can handle the IOException example we have discussed above, using a try-catchblock. We enclose the sensitive code that might throw an IOException with a try block. The catchblock only fires if the try block throws an IOException.

public class FileNotFound {

   public static void main(String args[]) {	    
FileWriter myWriter;

		try {

			myWriter = new FileWriter("C://filenotfound.txt");

			myWriter.write("Hi, I'm trying to write something.");
		    myWriter.close();

		} catch (IOException e) {

			System.out.println("Exception thrown: " + e);

		} finally {

			System.out.println("End of execution.");

		}

   }

}

Now, the console output changes from the system-generated message to the instructions we’ve given inside the catch block. The code throws [FileNotFoundException](https://docs.oracle.com/javase/9/docs/api/java/io/FileNotFoundException.html "FileNotFoundException") instead of IOException, which is a subclass of IOException and provides the closest description of the issue.

Exception thrown: java.io.FileNotFoundException: C:\filenotfound.txt (Access is denied)
End of execution.

Handling unchecked exceptions

You can also use try-catch blocks to handle an unchecked exception. Although handling unchecked exceptions is not obligatory, it’s a good idea to use a try-catch block for logging and monitoring purposes. The following example is from the Java Programming Wikibook and it demonstrates how logging an unchecked exception can be useful in servlet programming:

public long getLastModified(HttpServletRequest req) {


 try {


   ...


   return getTimeStamp();


   ...


 } catch(RuntimeException e) {


   log.error("Error during handling post request", e);


   throw e;


 }


}

The above code is called when an application server makes a request to the server. First, it catches runtime exceptions for logging purposes. Then, it throws them back to the server so that it can handle them. This way the application has its own logging system separate from the server logging and can detect all runtime exceptions on its own.

Throwing exceptions

Throwing exceptions is a specific programming technique in Java. You can only catch an exception that was thrown before, either by the Java platform or custom code. Exception throwing in Java happens with the [throw](https://docs.oracle.com/javase/tutorial/essential/exceptions/throwing.html "throw") statementArithmeticExceptionArrayIndexOutOfBoundsExceptionNullPointerException, and IOException in our examples were all thrown automatically by the Java platform.

The throw statement

The throw statement can be used with any throwable object that inherits from the Throwable class. It explicitly throws an exception from any block of code. Each throw statement inside a try block needs to be handled by a corresponding catch block.

For instance, our IOException example could also be written this way:

public class FileNotFound {

   public static void main(String args[]) {	    

	   FileWriter myWriter;

		try {

			myWriter = new FileWriter("C://filenotfound.txt");

			myWriter.write("Hi, I'm trying to write something.");
			myWriter.close();

			throw new IOException();

		} catch (IOException e) {

			System.out.println("Exception thrown: " + e);

		} finally {

			System.out.println("End of execution.");

		}

   }

}

You can add as many throw statements to a try block as you want, however, each has to have its own corresponding catch block.

Besides, catch blocks can also include their own throw statement. You could have seen that in the HttpServletRequest example before. When a catch statement throws an exception it needs to be further handled by the code calling the method. This technique is also referred to as rethrowing an exception.

The throws statement

Besides throw, Java also has a throws statement. It can be used in the signature of any method that might throw a checked exception. Say, you have a checked exception that would prevent the code from compiling but you don’t want to or can’t handle it within the current method. Using the throws keyword, you can indicate that the caller has to handle this exception with its own try-catch block.

This is how our IOException example looks like when we don’t handle it directly but delegate it to the caller method:

public class FileNotFound {

public static void main(String args[]) throws IOException {	    	    

	FileWriter myWriter;

	myWriter = new FileWriter("C://filenotfound.txt");

	myWriter.write("Hi, I'm trying to write something.");
	myWriter.close();		

}

}

As you can see, there’s no handling with a try-catch block. We just indicate the presence of the exception in the method signature so that the caller can decide how it wants to handle it.

You can add as many exceptions after the throws keyword in the method signature as you want. For example:

public static void main(String args[]) throws IOException, IllegalAccessException

Grouping exceptions

Grouping exceptions is a programming shortcut that allows you to handle multiple exceptions in a single catch block. This technique is available since Java 7. It’s a great solution when you want to run the same code on different exceptions. As you don’t have to handle each exception in a separate catch clause, you will have a much cleaner code base.

For example, you can handle IOException and IllegalAccessException in the same catch block:

catch (IOException | IllegalAccessException e) {

System.out.println("Exception thrown: " + e);

}

There’s one important rule, however. You can only group exceptions that are unrelated to each other. It’s not allowed to group exceptions that have a parent-child relationship. For example, the following code won’t compile, as FileNotFoundException is a subclass of IOException:

catch (IOException | FileNotFoundException e) {

System.out.println("Exception thrown: " + e);

}

The compiler returns an “unresolved compilation problem” message:

Exception in thread "main" java.lang.Error: Unresolved compilation problem:
	The exception FileNotFoundException is already caught by the alternative IOException

	at fileNotFound.FileNotFound.main(FileNotFound.java:22)

Nesting exceptions

Exception nesting happens in Java when one exception results in a second exception which results in a third exception, etc. As you deal with a whole chain of exceptions, nested exceptions are also called chained exceptions. The stack trace of an exception contains the chain of exceptions that have lead to the final exception.

You can nest a Java exception into another one using of the catch clause. Nested exceptions can help you identify why an exception has been thrown.

For instance, this is how exception nesting works with our IOException example:

public class FileNotFound {

   public static void main(String args[]) throws Exception {	    

	   FileWriter myWriter;

	    try {

			myWriter = new FileWriter("C://filenotfound.txt");

			myWriter.write("Hi, I'm trying to write something.");
		    myWriter.close();

		} catch (IOException e1) {

			Exception e2 = new Exception("Couldn't write into a non-existent file.", e1);

			throw e2;

		}

   }

}

As you can see the catch block creates a second exception called e2 that specifies the reason of e2and refers e1 as the cause of the exception. Then, it rethrows the new exception so that the caller method can handle it (or rethrow it again).

The Exception class has five possible constructors; the above example uses the following one:

public Exception(String message, Throwable cause)

If you run the example code, the console prints the whole stack trace:Exception in thread "main" java.lang.Exception: Couldn't write into non-existent file.
	at fileNotFound.FileNotFound.main(FileNotFound.java:21)
Caused by: java.io.FileNotFoundException: C:\filenotfound.txt (Access is denied)
	at java.base/java.io.FileOutputStream.open0(Native Method)
	at java.base/java.io.FileOutputStream.open(Unknown Source)
	at java.base/java.io.FileOutputStream.<init>(Unknown Source)
	at java.base/java.io.FileOutputStream.<init>(Unknown Source)
	at java.base/java.io.FileWriter.<init>(Unknown Source)
	at fileNotFound.FileNotFound.main(FileNotFound.java:14)

The stack trace starts with the custom message we defined as the first argument of e2. This shows that the new exception has been nested properly. The e2 exception also keeps a reference to e1, its nesting exception.

Note that we added e2 to the method signature using the throws keyword. So, the code that calls the main() method will have to handle e2 with a try-catch block. This kind of exception conversion can happen as long as a caller method is willing to handle it, instead of just re-throwing it to the next caller.

Need help discovering Java exceptions?

Java exceptions can be difficult to discover in the first place. Raygun Crash Reporting surfaces the stack trace where the error occurred so you can resolve issues quickly. Target Java errors with Raygun.

#java

3 Likes14.70 GEEK