Common Exception Java 8 Certification

You need to recognise three types of exceptions for the OCA exam: run-time exceptions, checked exceptions, and errors. We’ll look at common examples of each type. For the exam, you’ll need to recognise which type of an exception it is and whether it’s thrown by
the JVM or a programmer. So you can recognise them, we’ll show you some code examples for those exceptions.

Runtime Exceptions

Runtime exceptions extend RuntimeException. They don’t have to be handled or declared. They can be thrown by the programmer or by the JVM. Common runtime exceptions include the following:

  1. ArithmeticException Thrown by the JVM when code attempts to divide by zero ArrayIndexOutOfBoundsException Thrown by the JVM when code uses an illegal index to access an array
  2. ClassCastException Thrown by the JVM when an attempt is made to cast an exception to a subclass of which it is not an instance
  3. IllegalArgumentException Thrown by the programmer to indicate that a method has been passed an illegal or inappropriate argument
  4. NullPointerException Thrown by the JVM when there is a null reference where an object is required
  5. NumberFormatException Thrown by the programmer when an attempt is made to convert a string to a numeric type but the string doesn’t have an appropriate format


Trying to divide an int by zero gives an undefi ned result. When this occurs, the JVM will throw an ArithmeticException:
int answer = 11 / 0; Running this code results in the following output:

Exception in thread "main" java.lang.ArithmeticException: / by zero

Java doesn’t spell out the word “divide.” That’s okay, though, because we know that / is the division operator and that Java is trying to tell us division by zero occurred. The thread “main” is telling us the code was called directly or indirectly from a program with a main method. On the OCA exam, this is all the output we will see. Next comes the name of the exception, followed by extra information (if any) that goes with the exception.


You know by now that array indexes start with 0 and go up to 1 less than the length of the array—which means this code will throw an ArrayIndexOutOfBoundsException:

int[] countsOfMoose = new int[3];

This is a problem because there’s no such thing as a negative array index. Running this code yields the following output:

Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: -1

At least Java tells us what index was invalid. Can you see what’s wrong with this one?

int total = 0;
int[] countsOfMoose = new int[3];
for (int i = 0; i <= countsOfMoose.length; i++)
total += countsOfMoose[i];

The problem is that the for loop should have < instead of <=. On the final iteration of the loop, Java tries to call countsOfMoose[3], which is invalid. The array includes only three elements, making 2 the largest possible index. The output looks like this:

Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 3

Java tries to protect you from impossible casts. This code doesn’t compile because Integer is not a subclass of String:

String type = "moose";
Integer number = (Integer) type; // DOES NOT COMPILE

More complicated code thwarts Java’s attempts to protect you. When the cast fails at runtime, Java will throw a ClassCastException:

String type = "moose";
Object obj = type;
Integer number = (Integer) obj;

The compiler sees a cast from Object to Integer. This could be okay. The compiler doesn’t realize there’s a String in that Object. When the code runs, it yields the following output:

Exception in thread "main" java.lang.ClassCastException: java.lang.String
cannot be cast to java.lang.Integer

Java tells us both types that were involved in the problem, making it apparent what’s wrong.


IllegalArgumentException is a way for your program to protect itself. We first saw the following setter method in the Swan class in previous topics, “Methods and Encapsulation.”

6: public void setNumberEggs(int numberEggs) {// setter
7: if (numberEggs >= 0) // guard condition
8: this.numberEggs = numberEggs;
9: }

This code works, but we don’t really want to ignore the caller’s request when they tell us a Swan has –2 eggs. We want to tell the caller that something is wrong—preferably in a very obvious way that the caller can’t ignore so that the programmer will fix the problem.
Exceptions are an efficient way to do this. Seeing the code end with an exception is a great reminder that something is wrong:

public static void setNumberEggs(int numberEggs) {
if (numberEggs < 0)
throw new IllegalArgumentException(
"# eggs must not be negative");
this.numberEggs = numberEggs;

The program throws an exception when it’s not happy with the parameter values. The output looks like this:

Exception in thread "main" java.lang.IllegalArgumentException: # eggs must not be negative

Clearly this is a problem that must be fi xed if the programmer wants the program to do anything useful.


Instance variables and methods must be called on a non-null reference. If the reference is null, the JVM will throw a NullPointerException. It’s usually subtle, such as this example, which checks whether you remember instance variable references default to null.

String name;
public void printLength() throws NullPointerException {

Running this code results in this output:

Exception in thread "main" java.lang.NullPointerException


Java provides methods to convert strings to numbers. When these are passed an invalid value, they throw a NumberFormatException. The idea is similar to IllegalArgumentException. Since this is a common problem, Java gives it a separate class.
In fact, NumberFormatException is a subclass of IllegalArgumentException. Here’s an example of trying to convert something non-numeric into an int:


The output looks like this:

Exception in thread "main" java.lang.NumberFormatException: For input string: "abc"

Comments are closed.