Rules for handling anomalies of Java EE system

Exception processing is a problem that every Java programmer often faces, but many people have no principle, encounter unusual also do not know how to deal with, so encounter check abnormal try...catch randomly ... One, and then E.printstacktrace (), this practice is usually in addition to debugging a bit of a role, there is no value. For run-time exceptions, simply ignore them.

The reason is that many developers lack of understanding and analysis of anomalies, first of all should understand the Java exception architecture, a hierarchical inheritance of the relationship, you have to the hierarchy of rotten to the heart:

Throwable(必须检查)
　　　　　　　　　　　　　　　　　　　　 Error（非必须检查）
　　　　　　　　　　　　　　　　　　　　 Exception（必须检查）
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 RuntimeException（非必须检查）

In general, exception anomalies and their direct subclasses (except for runtimeexception) are referred to as check anomalies. The exception of RuntimeException and its subclasses is called an unchecked exception, also known as a Run-time exception.

For Throwable and error, the use of very little, generally used in some basic framework, not discussed here.

The following is the layered architecture of Java EE: The DAO layer, the business layer, the control layer, the display layer of the exception processing to do an analysis, and give the general processing criteria.

First, DAO layer exception handling

If you use the spring DAO template for implementation, the DAO layer does not check for exception throwing, and the code is elegant. However, if your DAO uses the original JDBC to write, at this time, you can not have to deal with the exception, because the unavoidable sqlexception will follow you. For an exception that already has this DAO level, what can you do about it? Rather than try...catch ..., it is better to let the exception be passed out in another unchecked way than to kill it. There are two advantages to doing this:

1, DAO's interface is not contaminated by the exception, if you throw the SqlException, if you change the spring DAO template, then the DAO interface will no longer throw the SqlException, so that your interface throws an exception is the pollution of the interface.

2), DAO exception propagated to higher-level processing, so that the cause of the exception is not lost, easy to troubleshoot or capture processing.

There is also an often troubling design problem: A lot of people ask, what kind of exception does that define, or just throw a throw runtimeexception (e)? For this problem, need to divide the situation, if the system is small, you can throw a throw runtimeexception (e) directly, but for a large modular system, do not throw this native unchecked exception, but to throw a custom unchecked exception, so not only for error, It also facilitates the handling of system exceptions, usually for each module, the coarse-grained definition of a run-time DAO exception. For example: throw new Modelxxxdaoruntimeexception ("...", e), for msg information, you can write or not write, according to the need to be flexible to throw.

Here common a very ignorant treatment, for each DAO to define an exception, oh, so tired not tired ah, how much significance, in the service layer when the call, if you want to capture, but also to catch a bunch of exceptions. This fatal problem is code chaos, maintenance difficulties, reading is also difficult, DAO's exception should be coarse granularity.

Second, the business layer exception handling

It's customary to call the business Layer a service layer or a services layer, service layer is the representative of the business logic, do not superstitious too many layers have much benefit, unless necessary, do not blindly divide unnecessary layers, the more the more the efficiency of the worse, according to the need for sufficient on the line.

Each method in the service interface represents a particular business, and this business must be a complete business, usually seeing some silly x practices, the database transaction is configured at the service level, and the service implementation is the DAO's direct call, and then, in the control layer (Action), Call a lot of service to complete a business, you are angry have no language, look down to find bricks to!!!

Figure out the above two questions and then look back at how the exception to deal with the service layer is usually dependent on DAO, and service layer is usually due to call other non-check exception methods and must face the problem of exception handling, here and DAO layer is different, WTF, then!

In general, a small module corresponds to a service, of course there may be two or more, for the service of this module to define an unchecked exception to cope with the inevitable anomaly check, This custom exception can be simply named Xxxserviceruntimeexception, and the caught exception is translated as an unchecked exception and thrown. I like to do this, because the foreground is the Java application, the foreground is the Web page, their Struts2 frame will automatically capture all the service layer of the exception, and the exception to the developers to free processing.

But there is one more situation, because of some special restrictions, if an exception occurs, what must be done, and the processing is hard, or call a service method, you must check what exceptions are handled, or you can throw unchecked custom exceptions, often this is a political reason. This practice is not respected, but it is not excluded.

In short, for the interface, as far as possible not to use abnormal pollution her!