On Java Development

All things related to Java development, from the perspective of a caveman.

Using Exceptions to Create UI Messages

without comments


This post shows how to write methods so that any processing errors, such as a “policy not found” error, can be managed effectively in a consistent way. The approach applies standard Java exception handling using try/catch blocks to throw errors back to the caller that started the process. The caller will then catch the error for further processing such as displaying the error to the user. For more information about standard Java error exception handling, see this link.

The presentation begins with the inner layer of the I/O processing and works outward to the user interface. The initial focus is on the exception classes showing how they are used.

Base Exception Class and Persistence Exception Class
First, these classes are included in baseproject, so there is nothing here to write. They are ready to use out-of-the box.

BaseException class is the base class within which the basic error handling methods reside. The class has a few overloaded constructors with which to instantiate the class. It is designed to be extended to provide specialized exception handling. BaseException is listed below.

PersistenceException, listed below, is designed to extend the BaseException as seen by the extends keyword. Doing this allows new functionality to be added to PersistenceException without modifying the base class. As the name implies PersistenceException is intended to be used when performing database oriented processing. By extending BaseException, other exception classes can be created for specific processes. The relationship between BaseException and PersistenceException sets the design pattern and is known as inheritance.

Using PersistenceException in a DAO

The method shown below is from the DAO designed to provide I/O support for the policy master (PSPMPOL). The throws keyword is used to identify the type of exception to be thrown back to the caller whenever an error is encountered. In this case the error will be related to not finding the policy. Since the operation is related to persistence, the PersistenceException class is employed.

As can be seen the DAO is very simple. It accepts company, block and policy and puts them into the composite key class. The heart of the operation begins on line 10, which is where the JPA Entity Manager’s find method is called while passing the composite key class. The resulting policy is received by the pspmpol object derived from the class PSPMPOL. If the policy isn’t found, pspmpol will be null and this is what we need to know about.

Lines 11-15 tests pspmpol for null. If true, the logic will instantiate an object from PersistenceException called pe which will also be given the body of the error message to be presented to the user who evoked this process. Line 14 then throws the exception, which is allowed because of the throws keyword seen on line 1.

The next section will present the method getRiders which is of the service class PSPMPOLService designed to be the interface to the client. It is the caller of the method above.

The PSPMPOLService Class

This class provides all of the methods needed to call the DAO methods for file PSPMPOL. It initiates the calls and performs additional processing responsibilities such as establishing the transaction boundaries and comiting or rolling back the transaction. This then leaves the DAO as dumb as a box of left-handed pliers.

Lines 11-18 establishes the transaction, calls the getPolicyRiders method of the DAO and then commits the transaction. With Hibernate, transactions must be active for all I/O. Without it Hibernate will throw a Transaction not active error.

Because the getPolicyRiders method throws the PersistenceException error when the policy isn’t found, control will be given to the logic beginning on line 20 where the exception is caught. The first task is to properly roll back the transaction. Again, this is required and a good habit to get used to. Next, the message relating to the error is extracted and logged (probably redundant) and control passes to line 32 where the Entity Manager closes the session and underlying connection to the database, both of which are also good programming habits.

In the next section that follows, we’ll see that control is passed back to the so-called managed bean, which is the code that manages the data on the screen and provides the layer between the screen and services.

Calling the Service to Perform I/O
The code presented below is cut from the managed bean that is the liaison between the screen and the service layer. The code is executed when the user selects the submit button on a dialog that allows for entry of company, block and policy.

The first line instantiates an object derived from the service class for the policy master. The logic then clears out the list that will receive the riders and then calls the service method getRiders presented in the previous section. Exceptions thrown using PersistenceException will be caught on line 5 which processes the error by setting the boolean isError to true, pulling the message out of the the pe object and then sending it to a FacesMessage object to be placed into the FacesContext so that the message state can be tested by the page logic.

The Get Riders Dialog

Shown below is the dialog presented to the user so that they can enter the company, block and policy. The values provided to the dialog are for a policy that does not exist.

This code of the xhtml page used to present the dialog is shown below.

The focus on for this part of the discussion begins with lines 49-70 which is the code segment that defines the submit button and the logic to be executed when the process completes which is to present an error message to the user informing them that the policy does not exist. The javascript defined using the oncomplete tag is executed when the process completes. Basically this logic tests to see if the simple field-level validation failed. This tests for the completeness of the form. If something is missing then the wait dialog, presented when the submit button was selected, is removed from view so that the user can fix the error and try again. For information about how the wait dialog is written, see this post.

The next logic segment beginning with the else statement on line 57 is processed when there are no errors with the entries provided to the dialog and the process of getting the riders completed normally. With that event, the code will hide the wait dialog and then the dialog for the company, block and policy. For clarity, both are shown in the image below.

When the DAO is not able to find the desired policy, the logic beginning at line 62 is executed. It tests the isError boolean of the managed bean to determine if the error dialog should be displayed with the error message captured in the PersistenceException thrown by the DAO. This error dialog with the message is shown below.


This post presented 2 simple classes that act as a small design pattern for exceptions processing. It showed how they are used by the DAO and Service class and how control is passed up the call stack back to the browser where an error message is presented to the user using an error message dialog. This represents a standard approach to error handling common to all web-applications.

Written by admin

January 23rd, 2014 at 6:35 pm

Leave a Reply

You must be logged in to post a comment.