When you write code for your application, you expect that it will execute without any problems. So, it is important to manage and detect all possible errors in your program. Even so, sometimes you may encounter surprises during program execution. These surprises may occur for various reasons, such as some careless mistake in the program, implementation of incorrect logic, loopholes in the code paths of the program, and so on. However, it is also true that many of the failures are beyond the control of a programmer. Programmers often term these unwanted situations as exceptions . Handling these exceptions is essential when you write any application.
Types of Mistakes
Compile-time error
Runtime error
Compile-time errors are detected by the Java compiler and are easy to detect. The Java compiler acts as your friend to figure out the error details. For example, it may point out a line number (where the error is encountered) and display a brief description of the error. Once you correct it, you need to recompile it to check whether the updated program is ready for execution. Sometimes, you may need to fix multiple errors, and, as a result, multiple recompilations may be needed. The Java compiler will not generate the class file if it finds these kinds of errors in your program.
Two typographical errors in Eclipse IDE
So, you can see that you missed the bracket { after the class definition and you forgot to put a semicolon at the end of line number 5.
This type of error is common but sometimes hard to find with human eyes at the very beginning. So, the Java compiler will rescue you in these situations.
Dividing an integer by 0
Trying to access an array element that is out of bounds of an array
Using a null object to invoke a method
Trying to do invalid conversions, such as trying to convert an invalid string to an integer
Intentionally in some places, I am using the term mistake instead of error. The reason will be revealed to you shortly.
Definition of Exception
You can define an exception as an event that breaks the normal execution or the instruction flow of the program.
When exceptional situations arise, an exception object is created and thrown into the method that created the exception. That method may or may not handle the exception. If it cannot handle the exception, it will pass the responsibility to another method. (Similar to our daily life, when a situation goes beyond our control, we seek advice from others.) If there is no method to take responsibility for handling a particular exception, an error dialog box appears (indicating an unhandled exception), and the execution of the program stops.
Points To Remember
An exception-handling mechanism deals with runtime errors, and if they are not handled properly, an application will produce unwanted output, and it may die prematurely. Therefore, you should try to write applications that can detect and handle surprises in a graceful manner and prevent the premature death of the application.
Demonstration 1
Key Points of the Exception-handling Mechanism
An exceptional object is created when a runtime error occurs. So, a Java exception is basically an object to describe an erroneous situation.
Any method in an application can raise surprises during the application’s runtime. If such a situation occurs, in programming terminology, you say that the method has thrown an exception.
You use the following keywords to deal with Java exceptions: try, catch, throw, throws, and finally.
You try to guard against an exception with a try-catch block . The code that may throw an exception is placed inside a try block, and this exceptional situation is handled inside a catch block. But if there is no exception raised in the try block, the catch blocks are bypassed completely.
You can associate multiple catch blocks with a try block. When a particular catch block handles the sudden surprise (the exception), you say that the catch block has caught the exception.
The code in the finally block must execute. A finally block is generally placed after a try block or a try-catch block. This block is used to perform some housekeeping so that the application can be gracefully closed. For example, if a file is already opened, you should close it here, or if you already allocated some resources, those should be released inside this block.
When an exception is raised inside a try block, the control jumps to the respective catch or finally block. The remaining part of the try block will not execute.
- Exceptions follow the inheritance hierarchy. So, it is important to remember the hierarchy, shown in Figure 10-2.
Figure 10-2Exception hierarchy
You can see that both the Exception class and the Error class are subclasses of the Throwable class, which in turn derives from Object (in the java.lang package). By other exceptions, I mean classes like IOException (already defined in Java), our own custom exception classes (not defined in Java), and so on. So, you can simply say that in Java, the Throwable class is the ultimate super class of all errors and exceptions.
Exceptions are broadly categorized into two types: checked and unchecked . The runtime exception classes (RuntimeException class and its subclasses) and error classes (Error class and its subclasses) fall into the category of unchecked exceptions, and the others remaining are called checked exceptions. You’ll see a detailed discussion of each category shortly, and Q&A 10.8 will summarize the details.
This chapter primarily focuses on runtime exceptions. Errors, in general, are caused by some catastrophic failures, like JVM being out of memory, stack overflow, and so on. You can hardly do anything with them. The Java runtime environment itself needs to take care of these severe situations.
When you create your custom exception classes, in general, you’ll subclass from the Exception class. But it is not a rule. So, in Demonstration 7, you’ll see that a custom exception class extends from the Throwable class, and in Demonstration 8, you will notice that a custom exception class inherits from the RuntimeException class.
You should order the catch blocks from most specific to most general. Otherwise, you will encounter compile-time errors. For example, suppose you have placed a catch block (say, catch block1) that can handle a parent-class exception before a catch block (say catch block2) that can handle only the derived-class exception. From the compiler’s point of view, it is an example of unreachable code, because in this case catch block1 is always capable of handling the exceptions that catch block2 can handle. Therefore, control does not need to reach catch block2 at all. You will examine this scenario in an upcoming example.
You can use any of these combinations: try-catch, try-catch-finally, or try-finally.
The Java runtime system can generate exceptions. At the same time, you can also create your own exception class and throw your own exception.
If you do not handle exceptions, a default handler of the Java runtime system will handle it on your behalf, and the program may die prematurely.
Points To Remember
In Java, the Throwable class is the ultimate super class of all errors and exceptions.
In an exception-handling mechanism, there is a key difference between Java and C#. There is no concept of the throws keyword in C#. This is a hot topic of debate.
Demonstration 2
When an exception was raised inside a try block, the control jumped to the respective catch block. The remaining part of the try block did not execute. (Notice that you are not seeing the line "So, the result of a/b is :" in the output.)
The code in the finally block executed even though the program encountered an exception. (Notice the line "I am in finally. You cannot skip me!" in the output).
To get the details of the exception, some built-in methods are already defined in the java.lang.Throwable class. The getMessage(), printStackTrace(), getCause(), etc. are some common examples in this category. I have used two of them—getMessage() and printStackTrace()—in this demonstration. For your immediate reference, I am just picking a sample source code snapshot to get details of the getMessage() method from Eclipse IDE, which is shown in Figure 10-3.
A sample source code snapshot from Eclipse IDE
Q&A Session
10.1 I could easily put an if block like if(b==0) before the division operation to avoid a 0 divisor, and in that case I could easily exclude the use of the try-catch block. Is this understanding correct?
You are considering only this simple example, which is why it appears to you this way. Yes, in this case, you can guard your code using your proposed method. However, think of a case where the value of b is also computed at runtime (for example, you may pick a random value from a specified range, and you cannot predict the value earlier). Also, if you need to put guards like this in all probable cases, your code may look clumsy and difficult to read. But if you like a defensive programming style, you may keep asking for a valid input. So, at the end, it’s your choice as to how you want to design your software.
Demonstration 3
Output:
When you compile and run the program, you may notice any of the following outputs. I have shown all possible outputs in different runs. You may get a different order because the value of b is generated at random.
When an exception is raised, only one catch block is executed. For example, if the block catch (ArithmeticException ex){..} can handle the exception, the block catch (Exception ex){..} does not need to handle the exception again.
- In the preceding program, all types of exceptions can be caught inside the catch (Exception ex) block, and so this block must be placed as the last catch block. For example, in this case:
The ArithmeticException class derives from the RuntimeException class, which in turn derives from the Exception class.
The ArrayIndexOutOfBoundsException class derives from the IndexOutOfBoundsException class, which in turn derives from the RuntimeException class, which in turn derives from the Exception class.
Note
In Eclipse, you can hover your mouse pointer on the exception name and then choose the option “Open Declaration” to reveal the inheritance hierarchy.
Multiple catch Clauses
Unreachable catch block
Exceptions follow the inheritance hierarchy. Therefore, you need to place catch blocks properly. It has already been mentioned that the ArithmeticException class derives from the RuntimeException class, which in turn derives from the Exception class. For your easy understanding, follow the associated comments in the program.
Point To Remember
When you deal with multiple catch blocks, you need to place the more-specific exception clause first. In other words, you should place the catch blocks from most specific to most general.
Q&A Session
Yes.
10.4 Then why do you need a catch block at all?
The catch block is used to handle the exception in some specified manner. At the same time, you must note that the actual use of finally is different. It has been previously mentioned that inside finally you should do housekeeping so that the application can be gracefully closed. For example, if a file is already opened, you should close it, or, if you already allocated some resources, those should be released inside this block (to prevent memory leaks). In Chapter 14, you will learn to use a try-with-resource statement, where by using the term “resource” we mean an object that must be closed after the program finishes execution.
10.5 What will happen if I encounter an exception inside a finally block?
You should not forget the purpose of finally, which basically is to close files, release occupied resources, etc. But if you put your erroneous logic in the finally block, you may encounter an exception again. (The solution is the same—you can guard against a probable exception in the finally block with a try-catch, try-finally, or try-catch-finally block. In fact, prior to Java 6, you may notice such usage to close a resource.)
Demonstration 4
It is also useful to note that if you kill or interrupt a thread, the finally block may not execute, even though other threads can run and make the application as a whole alive. You will learn about threads in Chapter 11.
Q&A Session
10.6 Up until now, you have given examples like ArrayIndexOutOfBoundsException, ArithmeticException, etc. How can I remember these names?
These are built-in exceptions in Java. All of these are already defined in the java.lang package. Since this package is the default package, you’ll get all these exceptions imported by default. Upon practice, you can remember their names. I personally take help from Eclipse. Similar IDEs can help you with this as well.
From this output, you know that an ArithmeticException is raised.
Throwing an Exception
Up until now, you have seen examples of handling exceptions thrown by the Java runtime system. When you process Java statements, you may encounter such exceptions due to the wrong logic, loopholes, and so forth. But there is an alternative way to raise an exception—you also have the freedom to throw an exception explicitly by using the throw keyword. This method is useful when you make your own application and want to control the exceptional situation.
where anObjectOfThrowable must be an instance of the Throwable class or its subclass.
Demonstration 5
Rethrowing an Exception
Sometimes you need to rethrow an exception; for example, when you want to write a log entry or when you want to send a new higher-level exception. When you rethrow an exception from a catch block, it is rethrown to the next enclosing try block. Demonstration 6 shows such an example.
Demonstration 6
You can see why logging some additional details before you rethrow an exception is important. As soon as you encountered the exception, you logged it, and from that log you discovered that the divisor (b) became 0 in the divide() method. If you do not use the try-catch block inside the divide() method and you do not log the values of a and b immediately, then you are dependent on the catch block inside the main() method only. In a case like this, when you see the final log statements, you may wonder why you see this exception even if the value of b is 1.
Note
You’ll learn to create and use your own exception shortly, and you may combine the original exception with your custom exception message and then rethrow it for better readability.
An exception type must be a subclass of Throwable
Use of throws Keyword
A throws keyword will be needed to indicate all the exceptions that a method can throw. Otherwise, you’ll encounter compile-time errors (except for the next point).
The previous rule is not applicable for Error or RuntimeException or any of their subclasses.
You must remember that checked exceptions must be included in a method’s throws list.
The upcoming demonstrations will illustrate these points in detail.
Note
Q&A 10.8 can help you to differentiate the checked exceptions from the unchecked exceptions. I suggest you go through Demonstration 7 and Demonstration 8 before you enter into that discussion.
Demonstration 7
You can see that inside DemoClass7, the method raiseException() is throwing an exception, but I have not used a try-catch block around this code. Instead, I have added throws statements after the method names, as follows:
It is used to confirm that this method has the capability of throwing the exception of type TestClassException. The class has a constructor to accept a String message, so you can provide a meaningful message when you intend to throw such exceptions.
If you ignore the throws clause and just use the following code in Demonstration 7:
Compile-time error because TestClassException is not included in raiseException()’s throws list
Demonstration 8
You can see that TestClass8Exception is derived from RuntimeException. So, it is not a checked exception. This is why the compiler will not raise any errors when you do not include this exception in the method’s throws list.
Checked Versus Unchecked Exceptions
Now you understand the difference between checked and unchecked exceptions. I have already mentioned that there are some kinds of exceptions where either a throws clause needs to list all of the exceptions that a method can throw or you need to handle the scenario with a try-catch block. Otherwise, you’ll encounter compile-time errors. This is why these are called checked exceptions or compile-time exceptions. The remaining exceptions are termed unchecked exceptions.
Note
As I mentioned before, to understand the difference between checked exceptions and unchecked exceptions, you may need to visit Demonstration 7 and Demonstration 8 again.
ClassNotFoundException
NoSuchMethodException
NoSuchFieldException
InstantiationException
CloneNotSupportedException
IllegalAccessException
InterruptedException
ArithmeticException
ArrayIndexOutOfBoundsException
IndexOutOfBoundsException
SecurityException
NullPointerException
Point To Remember
If a method can throw a checked exception, then either the method should specify the exception using the throws keyword or it needs to handle the exception itself using try-catch block. Otherwise, you’ll encounter compile-time errors.
Q&A Session
10.8 I understand that checked exceptions are subclasses of Exception. You are also saying that unchecked exceptions are subclasses of RuntimeException. But from the hierarchy, I am seeing that RuntimeException is also a direct subclass of Exception. Then how they become unchecked exceptions?
“The checked exception classes are all exception classes other than the unchecked exception classes. That is, the checked exception classes are Throwable and all its subclasses other than RuntimeException and its subclasses and Error and its subclasses.”
At the same time, it also says that “the unchecked exception classes are the run-time exception classes and the error classes.”
Following these rules, the Java compiler can detect the RuntimeException clearly. So, following the language specification, you can safely say that any exception that is a subclass of the RuntimeException or Error class is not a checked exception.
Discussion on Chained Exceptions
Sometimes you can receive an exception that may be caused by some other exception. So, you may be interested to know the original cause. The concept of chained exceptions comes into the picture in such a scenario.
Consider a very simple scenario of ArithmeticException, which you may receive when you divide an integer by 0. Sometimes your application can compute or update the divisor using various logic. So, when you receive this exception, the original cause may be the result of an I/O that can ultimately make the divisor zero.
Chained exceptions can help us to know about such exceptional scenarios, and at the same time they can point to the layer in which the actual error exists.
Demonstration 9
The OuterQuiz3Exception class inherits from the Exception class. So, it is a checked exception. Since you have not used a try-catch block in the raiseException() method, the throws clause is necessary for the raiseException() method now.
You needed to list all the exceptions in the throws list that the method can throw. But InnerQuiz3Exception is a subclass of OuterQuiz3Exception. So, only the inclusion of OuterQuiz3Exception in the throws list of the raiseException() method was sufficient for you. But if you include InnerQuiz3Exception also, there will be no compiler issue.
I am generating a random number between 0 (inclusive) and 2 (exclusive), so output may vary when an InnerQuiz3Exception is thrown (i.e., when b = 1).
Creating a Custom Exception
You have already seen some common uses of Java’s built-in exceptions. These are very handy, and, in most cases, they can serve your needs. But sometimes you may want to define your own exception class to get messages that are more meaningful to you. So, you may want to create your own exceptions to handle some specific situations in your application.
A common practice to create a user-defined exception class is to extend from the Exception class. You have learned that Exception is a subclass of the Throwable class. So, you can override or use the methods defined in the Throwable classes.
The Exception class does not have any method specific to it. But here you’ll see different overloaded version of constructors; for example, you will notice the presence of the following constructors. In the discussion of chained exceptions, you got to know about two of them. In the upcoming demonstration, you will see the use of another two:
Following convention, it is suggested that when you create your own exception, the class name should end with the word Exception.
Demonstration 10
Q&A Session
10.10 I understand that Java does not support pointers. But I am seeing that it supports NullPointerException. I am confused.
You need to understand the scenario. When you perform some illegal operations (for example, when you invoke a method incorrectly or try to access some fields incorrectly) through a null object, you encounter this exception. This exception generally indicates that you are treating a null object as an actual object, so your intended operation is illegal. Yes, some developers believe that something like NullReferenceException could be a better name for this type of exception.
At the same time, you also remember that Java designers believe that the use of pointers is one of the primary sources of injecting bugs into the application. So, they do not support any pointer datatypes.
10.11 It appears to me that I can suppress errors with exceptions. Am I right?
Yes. But it is never intended. Consider the following demonstration.
Demonstration 11
Q&A Session
10.12 Should I make my custom exceptions checked (or unchecked)?
If you can do something to recover from an exception, make it a checked exception; otherwise, make it unchecked. Based on your requirements, you can follow the approach of Demonstration 7 or Demonstration 8 to make your custom exception checked or unchecked.
10.13 You said earlier, “You may combine the original exception with your custom exception message and then rethrow it for better readability.” Can you show me a demonstration?
In the Java programming world, it’s very common to catch a built-in exception and rethrow the same exception via a custom exception for better readability and understanding. I discussed this regarding Demonstration 6.
Demonstration 12
Notice the message “The divisor becomes zero” appeared in your output, which is the actual cause of the ArithmeticException in this program.
Summary
What is an exception?
How can you handle errors in our program?
What are the common keywords used when we deal with exceptions in Java?
How should you place try, catch, and finally blocks in your program, and what is their purpose?
What are the different variations of the catch clause?
How can you throw an exception?
How can you rethrow an exception?
How is throw different from throws?
How can you classify exceptions? How are checked exceptions different from unchecked exceptions?
How can you make chained exceptions?
How do you make a custom exception?
How can you catch a built-in exception and combine it with a custom exception?