EXCEPTION HANDLING

Exceptions: checked/unchecked and try catch blocks

An Exception is a reaction by the Java runtime to your program doing something that puts your program into an undefined or corrupted state.

In such a case the runtime suspends execution of your program right at the instruction that committed the violation. If the offending statement is not wrapped inside a try/catch block the compiler will backtrack down the call stack until a try/catch block is found. If no try catch block is found your program will return to the command window and halt with an error message. In a case where no try catch is found for the offending code, your program will not be allowed to execute a single instruction and will return all the back to the command window or whatever environment it was executed from without executing any more of its code.

It is the Java philosophy that no program should continue to execute in a compromised state. Many languages will allow a program to continue running after it has dereferenced a null pointer or indexed an array out of bounds while making no requirement of the program to address that error.

Do you understand why continuing to run a compromised, corrupted program is dangerous?

Here are a few typical situations that trigger an Exception.

call Integer.parseInt( "fubar" ); (parseInt can't convert "fubar" to an int)
trying to open a disk file that is not there: Scanner infile = new Scanner ( new File("non_existent_file.txt") );
trying to dimension an array with an invalid dimension: int arr[] = new int[ -1 ];
indexing into an array with an invalid index: int x = arr[-256 ];
trying to allocate more memory than is available in the heap: int arr[] = new int[ 2000000000 ];

Methods throw Exceptions (indirectly) too. Although it is always a statement in a method that triggers an Exception, the method containing the offending statement can either wrap that statement in a try catch block or simply "pass the buck" and allow the runtime to go back to this methods calling method to see if that caller is taking responsibility. In this case the method that does not have a try catch block is throwing the exception back to caller instead of handling it.

Checked Exceptions vs. Unchecked Exceptions

If a method contains a statement capable of throwing a checked Exception, that method must either wrap the statement in a try/catch block or put a throws Exception tag after the method signature.

Checked Exceptions: Error that is often recoverable. Usually a result of bad inputs or missing resources.

FileNotFoundException: tried to open a file that is not there
FileIOException: file is there but you don't have privs to access it

Unchecked Exceptions: Often bad code that should not be recovered from. Should abort execution and fix the code!

NullPointerException: you put a dot '.' or []s after a ref var containing null value
ArrayIndexOutOfBoundsException
NumberFormatException: int x = Integer.parseInt("foobar");
ArithmeticException: divide by zero

Sometimes though, it is possible and desirable to recover from an unchecked Exception.

DEMO1 EXAMPLE OF AN UNCHECKED EXCEPTION: ExceptionsDemo1.java

Output of Demo1

Notice that neither main(), foo1() or foo2() completes. As soon as the exception triggers, control returns from foo2() to foo1(). As soon as control returned to foo1() at the call to foo2(), the runtime saw that foo1() was not handling the Exception either. Control then returned to main() at the call to foo1(). Since main() was not handling the Exception either, control returned to main's caller - the command line, and a stack trace of the offending code's call history is dumped onto the command window.


calling foo1()
In foo1()
calling foo2()
In foo2()
You entered int: 1234
Exception in thread "main" java.lang.NumberFormatException: For input string: "fubar"
        at java.lang.NumberFormatException.forInputString(Unknown Source)
        at java.lang.Integer.parseInt(Unknown Source)
        at java.lang.Integer.parseInt(Unknown Source)
        at ExceptionsDemo1.foo2(ExceptionsDemo1.java:44)
        at ExceptionsDemo1.foo1(ExceptionsDemo1.java:25)
        at ExceptionsDemo1.main(ExceptionsDemo1.java:16)

DEMO2 EXAMPLE OF A CHECKED EXCEPTION: ExceptionsDemo2.java

If we were to remove the throws IOException from the above program and recompile it, the compiler will give the following errors.

C:\Users\tim\Desktop\ExceptionHandling>javac ExceptionsDemo2.java
ExceptionsDemo2.java:26: error: unreported exception FileNotFoundException; must be caught or declared to be thrown
                Scanner infile = new Scanner (f );
                                 ^
1 error

C:\Users\tim\Desktop\ExceptionHandling>

USE TRY CATCH TO HANDLE EXCEPTIONS: ExceptionsDemo3.java

You probably noticed that the catch block looks similar to a method definition. When a statement inside the try block triggers an Exception, control jumps into the try block just as if the catch block was a method - and it brings into the catch block an Exception object containing info about what happened.

This mechanism might remind you of event programing when you clicked a JButton the runtime automatically called your actionPerformed method and passed in an event object containing info about the event that triggered the jump into the method.

The major difference in behavior with an Exception is that we don't return back from the catch block. Instead we execute the catch block and then drop past the end of the catch block and resume execution after it.

Stacking catch blocks

Often there are multiple statements in a try block that could throw different types of Exceptions. We could use a shotgun approach and just have one single catch block looking for Exception (the general case) that will catch any Exception (and any sub type of Exception) that occurs. Usually we want to know which specific type of Exception occurred and handle it distinctly. To do that we stack multiple catch blocks under the single try block. Always put the more specific sub type first and the most general at the bottom. Each block is written such that it will only get triggered for the specific Exception type in the catch definition.

Once we have a separate catch block under the try block for each kind of Exception our try code might produce, we can now put a general Exception catch bloc at the very bottom as a catch all in case an unplanned/unexpected Exception occurs. It's similar to a long chained if else . . . if else statement with an unqualified else at the bottom. If none of the if tests match then the else at the bottom is the catch all case that executes. Like a chained if else, our catch blocks are stacked and we only execute at most one of them if an exception triggers, and that will be the first case that matches. This is why we must put the specific Exception subtypes at the top and save the general catch all Exception for the bottom.

If there is a finally block at the bottom - that finally block IS executed. Understand that even if the code in the try block executes cleanly with no exception - the finally block STILL executes. Always keep that in mind that if you write a finally block at the bottom underneath your catch block()s, it will execute regardless of whether an exception is triggered or not.

One more special type of catch block. The finally block

A special block named 'finally' can be added to the very bottom of any catch stack (even below the general Exception catch all block). Understand that even if the code in the try block executes cleanly with no exception - the finally block STILL executes. If the try block DOES trigger an Exception, the first catch block that matches the Exception type will execute but then the finally block will executes also. Always keep that in mind that if you write a finally block at the bottom underneath your catch block()s it will execute regardless of whether an exception is triggered or not.

USE TRY CATCH TO HANDLE EXCEPTIONS: ExceptionsDemo4.java

Output of the above program


calling foo1()
1st line of infile was: Hello World
Caught NumberFormatException: java.lang.NumberFormatException: For input string: "Hello World"
returning from main()

YOU CAN MANUALLY THROW AN EXCEPTION: ExceptionsDemo5.java

Sometimes it is convenient to manually throw an exception yourself because you want to treat a case that does not put your program into an undefined state (i.e. its not an error) as if it is an error and handle it with a catch block just a like a an exception thrown by the runtime.

real