Handling Exceptions with try..catch

Most programs are written as a sequence of steps that the computer carries out one after another. The path the program follows from start to finish is usually that sequence. Sometimes, though, something happens while the program is running that pulls it off that path. Programmers have a word for these moments: exception. This article explains what an exception does to the path a program takes, how Java represents an exception, and how try..catch fits into the picture as the place where such an event can be handled.

Before looking at Java, it helps to picture a simple program as a list of statements. Imagine a program with four statements that run in order. If nothing unusual happens, the computer runs statement one, then two, then three, then four. Now imagine that during statement two, something happens that the program did not plan for. Where does the computer go next? Keep that question in mind as you read the next section, because answering it is the whole point of the concept.

The diagram below compares the two situations. The top path is the ordinary path, where each statement leads to the next. The middle of the disrupted path is the point where the planned order is interrupted. The exception object is the form the event takes once it exists in the program, and the try..catch handler at the end is the place the source associates with dealing with this kind of event. The diagram is a map of the idea rather than a complete description of every step the runtime takes.

Read the diagram as a comparison. On the normal path, Statement 3 and Statement 4 run because execution simply continues in order. On the disrupted path, the event in the middle changes where execution goes. The statements that were planned after the event do not continue in their planned order, and control moves toward the exception object and the handler. The key idea is not the specific steps but the change of route: an exception is defined by the fact that it changes which part of the program runs next.

In Java, exceptions are represented as objects of type Exception. This matters because an object can be created, passed around, and examined like any other value in the program. Instead of the event being an abstract interruption with no form, it becomes something the program can hold and work with.

The word Exception names the general category. The exceptions a program actually meets are usually defined by subclasses of Exception, which are narrower classes built on top of the general one. So Exception is the broad kind of thing, and specific exception types are the more precise kinds that sit beneath it.

Different subclasses represent different types of exceptions, so each specific type stands for a particular category of disruption. The source highlights two examples: NumberFormatException and IllegalArgumentException. Both are named as specific kinds of Exception. The diagram below shows the relationship the source describes: the general Exception type with specific subclasses beneath it.

The source does not describe any further relationship between these two subclasses, so the diagram places them side by side rather than inventing a parent-child link between them. The source also states that it looks at only these two types in that section. Many other exception types exist beyond the two shown, so treat them as examples of a larger family rather than a complete list.

It would be natural to call every disruption an error, but the source deliberately avoids that word. The reason is that some exceptions are not errors at all. You can sometimes think of an exception as simply another way to organize a program. An event that changes the path through the code is not always a mistake. It may be a situation the program was designed to route differently.