8: Exceptions to the Rule in Java

Maker QR Code in Java 8: Exceptions to the Rule

That s nice, but what can you do with it You don t have to do anything However, when handling an exception, you now have the option of finding out whether it contains any additional chained exceptions A new method in the Throwable hierarchy is getCause, which returns the Throwable that caused the current Throwable This means you can programmatically retrieve the entire history of the exception and output the information to a log or system console See the logExceptionChain method in Listing 8-3 for an example of how to retrieve chained exception information A helpful article on the chained exceptions feature of Java version 14 can be found at

Another form of defensive programming is the use of assertions Assertions can be characterized as lazy exceptions, in the sense that an assertion behaves somewhat like an exception yet takes a lot less code on the part of the pro grammer The following example clarifies this technique Suppose that you ve written a method that gets a reference to a poList object and then uses the reference to update information in the list:

public void updateList() { do something here to get a reference to a poList object // assert that we actually got the reference to poList assert poList != null; continue on with processing the poList }

Under almost all conditions, you will get the reference (in this example, to a poList object) successfully To cover the unlikely possibility that you can t get the reference, you assert that poList should not be null at this point If it turns out to be null, an AssertionError is thrown The assert statement has two forms The first form is as follows:

assert expression1;

assert expression1 : expression2;

The main difference between these two forms is that the first form throws AssertError without any message, but the second form uses expression2 as the message in AssertError When compiling code with assertions, you must have JDK 14 or greater Otherwise, the compiler will not allow the use of the assert statement If you re using the Eclipse IDE, you need only version 14 JRE or better installed and 14 selected as the compiler compliance level To make sure that the compiler compliance level is set correctly, do the following: 1 Choose Window Preferences The Preferences dialog box appears 2 On the left side of the screen, choose Java Click the plus sign (+) next to Java to see the other options 3 Click Compiler The Complier dialog box appears 4 Choose the Compliance and Classfiles tab Make sure that the

Compiler compliance level is set to 14 (see Figure 8-2)

If you re using the command line to invoke the compiler, use the source 14 command-line option to ensure that the compiler will accept assert statements

The assert statements are interesting because you can turn them on and off at runtime Assertions are turned off by default To turn assertions on, use the ea or enableassertions command-line switch when starting the pro gram For example:

turns on (enables) assertion checking in myProgram When developing and testing, assertions are valuable debugging tools for shak ing out error conditions But in production code, these conditions should no longer exist If some doubt exists about whether to use an assertion or throw an exception, consider whether the condition could arise in a production state or not If it could, throw the exception To find out more about assertions and their use, look at the following Web site:

You have two choices for exception handling in Struts: use declarative excep tion handling (explained in the next section) or handle the exceptions yourself In Struts, the Action classes are the most likely candidates for handling exceptions because they re generally the root class of other classes that you might have written for your application Therefore, the Action class should probably catch all checked exceptions The handling of all exceptions in the Action class should be pretty much the same: 1 Save information about the exception 2 Recover from the error condition, if possible 3 If necessary, provide the user with a clear and concise message that explains what has happened and what the user should do (if anything) to correct the problem 4 When it is not possible to recover from the error, fail in a graceful way These four steps are discussed in this section