Catching Errors in Java - dummies

By John Paul Mueller

Many of the Java code examples you find for learning purposes will include error trapping in them. The examples won’t bury you in error trapping, but they’ll make good error trapping techniques part of the application code whenever possible (and the error trapping code doesn’t completely hide the purpose of the example).

With this in mind, the following sections provide an overview of the techniques used to catch errors. You’ll see three different levels of error trapping commonly employed in Java applications.

Error trapping is the act of detecting an exception and telling the JRE that you plan to do something with it. The JRE responds by not passing the error up to the caller of the current method and instead relies on the current method to fix the problem.

Error trapping is normally associated with the try portion of a try…catch statement, while error handling is normally associated with the catch portion of a try…catch statement.

Optional error handling

The phrase “optional error handling” is a bit of a misnomer. It’s optional only because Java doesn’t require you to perform it as part of using the various objects in your application. Every application you build should include some level of error handling, even if Java doesn’t require you to add it.

In fact, adding error handling to every application you create, even simple test applications, will help you become proficient in this aspect of Java programming and put you ahead of developers who don’t follow this practice.

Error handling is the act of resolving an exception that the application has trapped. In some cases, handling the error means displaying a message to the user and asking for a correction. However, error handling can take many forms, some of them completely automated and invisible to the user. This act is normally associated with the catch portion of a try…catch statement.

Handling more-specific to less-specific errors

Most applications can generate more than one exception. In addition, you may not be able to detect precisely which exceptions an application will generate. In this case, you need to provide multiple catch clauses for the try…catch statement. Each catch clause specializes in a particular kind of error.

In addition, you can use generic exception handlers for those situations when your application encounters errors that aren’t within the set that you originally anticipated.

Using Optional objects to avoid exceptions

Of all the exceptions you might see when working with Java, the NullPointerException (or NPE) is the most prevalent and sometimes the hardest to diagnose. A NullPointerException happens any time you pass a null value to a Java function that was expecting an actual value. The problem is that not every situation that creates an NPE is actually a problem.

Sometimes you expect to have a null value occur and need some method for dealing with it. For example, consider the situation where you want to find a specific value in a list of potential values. It’s entirely possible that you won’t find the value you want, resulting in a null value return.

If you then try to process the null value, you get an NPE. Because you had expected null values to occur, finding the error can be horribly difficult.

Until now, it was hard for human developers to understand the black-and-white thinking of a computer. Java 8 now provides Optional objects to deal with the situation where a return value from a function is optional rather than required.