Exception Handling is probably the most useful of the topics that are covered under the SCJP exam. Exception handling helps us catch or identify abnormal scenarios in our code and handle them appropriately instead of throwing up a random error on the front-end (User Interface) of the application.

Exception handling allows developers to detect errors easily without writing special code to test return values. Even better, it lets us keep exception-handling code cleanly separated from the exception-generating code. It also lets us use the same exception-handling code to deal with a range of possible exceptions.

Catching Exceptions - Using try and catch

The term "exception" means "exceptional condition" and is an occurrence that alters the normal program flow. A bunch of things can lead to exceptions, including hardware failures, resource exhaustion, and good old bugs. When an exceptional event occurs in Java, an exception is said to be "thrown." The code that's responsible for doing something about the exception is called an "exception handler," and it "catches and handles" the thrown exception.

Exception handling works by transferring the execution of a program to an appropriate exception handler when an exception occurs. For ex: Your website displays the users bank account details. Suddenly if the bank database is down, imaging how the user would feel if an abrupt error page with numerous lines of java exception messages spewed all over the screen? First of all, it would be embarrassing and second of all, the user will get annoyed. Instead, if your code catches this database down scenario and displays a graceful message on screen saying "We are currently experiencing some difficulties in our system. Kindly try after some time. Thank you" it would be much better isn't it? That is exactly why we have or rather why we need Exception Handling.

To do this, we use the try and catch keywords. The try is used to define a block of code in which exceptions may occur. This block of code is called a guarded region (which really means "risky code goes here"). One or more catch clauses match a specific exception to a block of code that handles it. Here's how it looks in pseudocode:

1. try {

2. // This is the "guarded region"

3. // All your bank database access code goes here

4. // And any other code that might process that data

5. // We may have many code lines here

6. }

7. catch(DatabaseDownException) {

8. // Put code here that handles this exception.

9. // Put the graceful error message here

10. // This is the last line of the exception handler.

11. }

12. catch(SomeOtherException) {

13. // Put code here that handles this exception

14. }

15.

16. // Some other unguarded code continues from here

In this pseudocode example, lines 2 through 5 constitute the guarded region that is governed by the try clause. Line 7 is an exception handler for an exception of type DatabaseDownException. Line 12 is an exception handler for an exception of type SomeOtherException. Notice that the catch blocks immediately follow the try block. This is a requirement; if you have one or more catch blocks, they must immediately follow the try block. Additionally, the catch blocks must all follow each other, without any other statements or blocks in between. Also, the order in which the catch blocks appear matters. For now just know this. We will see more in detail about their order a little bit later.

Execution of the guarded region starts at line 2. If the program executes all the way past line 5 with no exceptions being thrown, execution will transfer to line 15 and continue downward. However, if at any time in lines 2 through 5 (the try block) an exception is thrown of type DatabaseDownException, execution will immediately transfer to line 7. Lines 8 through 10 will then be executed so that the entire catch block runs, and then execution will transfer to line 15 and continue.

Note that if an exception occurred on, say, line 3 of the try block, the rest of the lines in the try block (4 and 5) would never be executed. Once control jumps to the catch block, it never returns to complete the balance of the try block. This is exactly what you want, though. Imagine your code looks something like this pseudocode:

try {

getTheFileFromOverNetwork

readFromTheFileAndPopulateTable

}

catch(CantGetFileFromNetwork) {

displayNetworkErrorMessage

}

The preceding pseudocode demonstrates how you typically work with exceptions. Code that's dependent on a risky operation (as populating a table with file data is dependent on getting the file from the network) is grouped into a try block in such a way that if, say, the first operation fails, you won't continue trying to run other code that's also guaranteed to fail. In the pseudocode example, you won't be able to read from the file if you can't get the file off the network in the first place.

One of the benefits of using exception handling is that code to handle any particular exception that may occur in the governed region needs to be written only once. Returning to our earlier code example, there may be three different places in our try block that can generate a DatabaseDownException, but wherever it occurs it will be handled by the same catch block (on line 7).