An exception-handling framework for Java EE applications

In most Java projects, most of the code is boilerplate code. Exception handling belongs to this type of code. Even if the business logic is only 3 to 4 lines of code, the code used for exception handling also accounts for 10 to 20 rows. This article discusses how to keep exception handling simple and intuitive so that developers can concentrate on developing business logic rather than wasting time on boilerplate code that writes exception handling. This article also describes the basics and guidelines for creating and handling exceptions in the Java EE environment, and proposes some business problems that can be resolved using exceptions. This article uses the Struts framework as the representation implementation, but the method applies to any representation implementation.

Scenes using checked and unchecked exceptions

Have you ever wondered why you put a try-catch block around a well-written block of code, even though you know you can't handle them, and you're only content to put them in a catch block? You might want to know why you can't put this work in a concentrated place. In most cases, this place is a front-end controller for the Java EE application. In other words, developers don't get distracted by them because they don't have to be asked a lot. However, what happens if a method name contains a throws clause? Developers either have to catch these exceptions or place them in the throws clause of their own methods. This is the root of the pain! Fortunately, the Java API has a class of exceptions called unchecked exception that do not have to be caught. However, there is still a problem: what is the basis for determining which are checked exceptions and which are unchecked exceptions? Here are some guiding principles:

An exception that an end user cannot take a valid action should be an unchecked exception. For example, a fatal and unrecoverable exception should be unchecked. It makes no sense to have xmlparseexception (thrown when parsing an XML file) as a checked exception, because the only measure that can be taken is to solve the underlying problem based on exception tracking. By extending java.lang.RuntimeException, you can create a custom unchecked exception.

In an application, the exception associated with a user action should be a checked exception. Checked exceptions require clients to capture them. You might ask, why not treat all the anomalies as unchecked. The problem with this is that some of these exceptions cannot be caught in the right place. This poses a larger problem because errors are recognized only at run time. Examples of checked exceptions are business validation exceptions, security exceptions, and so on.

Exception throw Policy

Captures only basic application exceptions (assumed to be baseappexception) and declares in the throws clause

In most Java EE applications, the decision about which error message should be displayed on the interface for an exception can only be made in the presentation layer. This poses another problem: why can't we put such decisions in a public place? In the Java EE application, the front-end controller is a centralized location for common processing.

In addition, there must be a common mechanism for propagating exceptions. Exceptions also need to be addressed in a pervasive manner. To do this, we always need to capture the basic application exception baseappexception on the controller side. This means that we need to put the baseappexception exception (only this exception) into the throws clause of each method that can throw a checked exception. The idea here is to use polymorphism to hide the actual implementation of the exception. We capture baseappexception in the controller, but the specific exception instance thrown may be any of several derived exception classes. With this approach, you can gain a lot of flexibility in exception handling:

There is no need to put a large number of checked exceptions in the throws clause. Only one exception is required in the throws clause.

There is no need to use a confusing catch block again for application exceptions. If you need to process them, a catch block (for baseappexception) is sufficient.

Developers do not need to do exception handling (logging and getting error codes) in person. This abstraction is done by Exceptionhandler and will be discussed later in this article.

Even if you later introduce more exceptions into the method implementation, the method name does not change, so there is no need to modify the client code, or it can cause a ripple effect. However, the thrown exception needs to be specified in the method's Javadoc so that the client can see the method constraints.

An example of throwing a checked exception is given below:

public void updateUser(UserDTO userDTO)
throws BaseAppException{
　 UserDAO userDAO = new UserDAO();
　 UserDAO.updateUser(userDTO);
　 ...
　 if(...)
　 throw new RegionNotActiveException("Selected region is not active");
}
Controller Method:
...
try{
　 User user = new User();
　 user.updateUser(userDTO);
}catch(BaseAppException ex){
　 //ExceptionHandler is used to handle
　 //all exceptions derived from BaseAppException
}
...