Best practices for EJB exception handling

As Java EE becomes the choice of enterprise development platform, more and more Java based applications will be put into production. One of the important components of the Java EE platform is the Enterprise JavaBean (EJB) API. Java EE and EJB technology provide many advantages together, but there are some new challenges. In particular, the enterprise system, any problems must be quickly resolved. In this article, Enterprise Java programming veteran Srikanth Shenoy shows his best practices in EJB exception handling that can solve problems faster.

In the Hello-world case, exception handling is very simple. Whenever an exception is encountered for a method, the exception is caught and the stack trace is printed or the method is declared to throw an exception. Unfortunately, this approach is not sufficient to deal with the various types of anomalies that arise in reality. In a production system, when an exception is thrown, it is likely that the end user is unable to process his or her request. When such an exception occurs, the end user usually wants to:

There's a clear message that there's been a mistake.

With a unique error number, he can access the customer support system that can be easily obtained

The problem is quickly resolved and can be assured that his request has been processed or will be processed within the set time period

Ideally, enterprise-class systems will not only provide these basic services to customers, but will also prepare some of the necessary back-end mechanisms. For example, the customer service team should receive an immediate error notification so that the service representative will be aware of the problem before the customer calls for help. In addition, the service representative should be able to cross-reference the user's unique error number and product log to quickly identify the problem-preferably by locating the problem to the exact line number or the exact method. To provide end users and support teams with the tools and services they need, when building a system, you have to be aware of all the places where the system might be problematic.

In this article, we'll talk about exception handling in an EJB based system. We'll start with a review of the basics of exception handling, including the use of the log utility, and then quickly move on to a more detailed discussion of how EJB technology defines and manages different types of exceptions. After that, we'll look at the pros and cons of some common exception handling solutions with some code examples, and I'll show my own best practices for leveraging EJB exception handling.

Please note that this article assumes that you are familiar with Java EE and EJB technology. You should understand the differences between entity beans and session beans. If you have a little knowledge of the persistence of Bean management (bean-managed persistence (BMP)) and container-managed persistence (container-managed persistence (CMP)) in the Entity bean context, is also helpful. See the Resources section for more information on Java EE and EJB technology.

Exception Handling Basics

The first step in resolving a system error is to create a test system that has the same structure as the production system, and then track all the code that caused the exception to be thrown, along with all the different branches in the code. In a distributed application, it is most likely that the debugger does not work, so you might track the exception with the System.out.println () method. System.out.println is very convenient, but it costs a lot. During disk I/O, System.out.println synchronizes the I/O processing, which greatly reduces throughput. By default, the stack trace is logged to the console. However, in a production system, it is not feasible to browse the console to see exception tracking. Also, there is no guarantee that the stack trace will be displayed in the production system because, on NT, the system administrator can map System.out and System.err to ", on UNIX, to Dev/null. In addition, if you run the Java EE Application Server as an NT service, there will not even be a console. Even if you redirect the console log to an output file, the file is likely to be rewritten when the product Java application Server restarts.

The principle of exception handling

Here are some universally accepted principles of exception handling:

If you cannot handle an exception, do not capture it.

If an exception is caught, please do not dispose of it indiscriminately.

Try to catch an exception where it is thrown near the exception.

Record it in the log where the exception is caught unless you intend to throw it back.

Construct your method in accordance with how fine-grained your exception handling must be.

Several types of exceptions need to be used, especially for application exceptions.

1th clearly contradicts the 3rd. The real solution is the tradeoff between how close you are to throwing an exception, and how far you can leave the exception before you completely lose the intent or content of the original exception.

Note: Although the application of these principles is pervasive in all EJB exception handling mechanisms, they are not specifically for EJB exception handling.

For these reasons, it is not an option to assemble the code into a product and include System.out.println at the same time. Using SYSTEM.OUT.PRINTLN during a test and then removing System.out.println before forming a product is not a good policy because doing so means that your product code does not run the same way as the test code. What you need is a declarative control log mechanism to make your test code and product code the same, and minimize the performance cost to the product when the log is closed declaratively.

The solution here is obviously to use a log utility. With the appropriate coding conventions, the log utility will be responsible for accurately recording any type of message, whether it be a system error or some warning. So, we'll talk about the log utility before we go further.