Java exceptions: Common terminology with examples
Posted Oct 25, 2022 | 12 min. (2384 words)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 understand Java exceptions.
Quick navigation
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:
- Unchecked exceptions (runtime exceptions)
- 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
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
:
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
. It’s also among the top 4 Java exceptions Raygun 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
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
class is the superclass of all Java exceptions and errors. It has two subclasses, Error
and Exception
but they don’t represent checked and unchecked exceptions. The Exception
class has a subclass called RuntimeException
that contains most unchecked exceptions. All other subclasses of Exception
are handled as checked exceptions. Besides runtime exceptions, errors also count as unchecked exceptions.
So:
- Subclasses of
Exception
except for the subclasses ofRuntimeException
are regarded as checked exceptions. - Subclasses of
Error
andRuntimeException
are regarded as unchecked exceptions.
Error
, Exception
, 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 try
, catch
, 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-catch
block. We enclose the sensitive code that might throw an IOException
with a try
block. The catch
block 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
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
statement. ArithmeticException
, ArrayIndexOutOfBoundsException
, NullPointerException
, 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 e2
and 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)
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.