The Exception Class Hierarchy

In your own small projects, you may end up with a few classes which use inheritance, but often not more than a few. However, many useful libraries, which you are likely to end up using, make extensive use of it. Often these libraries have a lot of classes, which can be daunting to the uninitiated, but with a diagram it is often easy to understand the structure of these libraries. For example, when you create Graphical User Interfaces (GUIs) there are different classes that represent components (e.g. a button, a text field) and containers that are components themselves and can contain one or more other components themselves (e.g. a tab-pane). They also contain ccomponents that allow you to specify the layout of components, and classes that help specify actions, that can for example be used if a user clicks a button. Typically, for each type of component there is a specific class that has some general Component class as a super-class, whereas only some of them will have the Container class as a super-class, which by itself can also have Component as a super-class.

Understanding such hierarchies of classes, a class hierarchy diagram provides insight into the structure of a library you are using. In these diagrams, we follow the following conventions:

Note that the superclass has the form of a rhombus and is thus an abstract class here, whilst the subclass has the form of a rectangle and is therefore a regular class.

We will now consider one class hierarchies from the standard library: the Exception class hierarchy. We hope that this will give you even more insight on the exceptions we learned about last week.

Unchecked exceptions (those we do not need to catch) are either subclasses of Error or RuntimeException. These have a green background in our picture. All other exceptions must be caught and are called checked exceptions. These have a blue background in our picture.

The answer on whether an exception must be caught or may be caught can thus be found by looking at the Exception hierarchy. Unchecked Exceptions do not have to be caught and are either a subclass of Error or RuntimeException. All other exceptions are Checked Exceptions and must be caught. You can even create your own exception types by writing public class MyException extends IllegalArgumentException {...}. If you want it to be unchecked, you put them underneath the RuntimeException in the Exception class hierarchy, and otherwise, in case of a checked exception, you let it be a subclass of Exception, but not of RuntimeException.

NB. Please note that you do not have to learn the upper hierarchy diagram by heart. You can always figure out these relationship from the reference that is provided during the exam. You do need to remember that unchecked exceptions are all types that are subtypes of Error and RuntimeException, and you should be able to figure out the rest using the extends relationships listed in the reference.