Exception and Exception Handling framework

From: http://www.ibm.com/developerworks/cn/java/j-lo-exceptionframework/index.html

Http://www.ibm.com/developerworks/cn/java/j-lo-exception/

Http://www.packtpub.com/article/exceptions-and-logging-in-apache-struts2

J2EE system Exception Handling principles http://www.jz123.cn/text/1925556.html

10-way http://blog.csdn.net/caihongshijie6/article/details/8759895 for exception handling in Java

Java Exception Handling Classification

Java exceptions can be divided into detecting exceptions, non-detecting exceptions, and custom exceptions.

Exception Detection

The exception can be detected and verified by the compiler. For any method that declares that an exception is thrown, the compiler will enforce the processing or declaration rules. For example, sqlexecption is a detection exception. When you connect to JDBC, the compiler will not be able to catch this exception and compilation is not allowed.

Non-detect exceptions

Non-detect exceptions do not follow the handling or declaration rules. When such exceptions are generated, the compiler does not check whether such exceptions have been resolved. For example, an array has three lengths. When you use a subscript of 3, an array subscript exception occurs. JVM does not detect this exception. It depends on the programmer. There are two main classes that define non-detection exceptions: runtimeexception and error.

The error subclass belongs to non-detection exceptions because it cannot predict their generation time. If the Java application has insufficient memory, an outofmemoryerror may occur at any time. The cause is generally not a special call of the application, but a JVM issue. In addition, error generally indicates that the application cannot solve a serious problem.

The runtimeexception class is also a non-detect exception, because running exceptions caused by common JVM operations may occur at any time. Such exceptions are generally caused by specific operations. However, these operations frequently occur in Java applications. Therefore, they are not subject to compiler checks and processing or declaration rules.

Custom exception

Custom exceptions are used to indicate some types of errors in the application and provide new meanings for one or more problems that may occur in the code. It can display the similarity of errors between multiple locations of the Code, or distinguish one or more errors that may cause similar issues during code running, or give the specific meaning of a group of errors in the application. For example, an empty queue attempts to delete an element, and an element is added when the queue is full. You need to customize two exceptions to handle these two cases.

Back to Top

Java Exception Handling principles and taboos

Java Exception Handling principles

1. Handle exceptions as much as possible

   To handle exceptions as much as possible, if the conditions are not allowed and cannot be processed in your own code, consider declaring exceptions. If you manually avoid handling exceptions in the Code and make declarations only, this is a practice of errors and dependencies.

2. Solve specific problems

   Some of the advantages of exceptions are that they provide different processing operations for different types of problems. The key to effective exception handling is to identify specific fault scenarios and develop specific actions to solve such scenarios. To make full use of exception handling capabilities, you need to build a specific processor block for a specific type of problems.

3. Record exceptions that may affect the application program running

   Take at least some permanent methods to record exceptions that may affect application operations. Ideally, it is certainly the first time to solve the basic problem that causes exceptions. However, no matter which processing operation is used, the potential key issues should generally be recorded. Although this operation is simple, it helps you track the cause of complex problems in your application with little time.

4. Convert exceptions to business context as appropriate

   To notify an application of a specific issue, it is necessary to convert the application into different forms. If an exception is indicated by a specific service status, the code is easier to maintain. In a sense, whenever an exception is transmitted to a different context (that is, another technical layer), the exception should be converted into a form that is meaningful to the new context.

Java Exception Handling taboos

1. Do not ignore exceptions.

   One of the most dangerous actions in exception handling blocks is to handle exceptions without notice. For example:

   1 try{2 Class.forName("business.domain.Customer");3 }4 catch (ClassNotFoundException exc){}

   Similar code blocks are often seen in code blocks. Some people always like to easily and quickly write empty processor blocks when writing code, and "comfort" claims to be prepared to add the recovery code later, however, this "Post" becomes "never ".

   What are the disadvantages of this approach? If exceptions do not have any negative impact on other parts of the application. But this is often not the case. Exceptions disrupt the application state. At this time, such code is no different from hacking.

   If the impact is mild, the application may have weird behavior. For example, a value set by the application is missing or the GUI is invalid. If the problem is serious, the application may have a major problem because the exception does not record the original fault point and is difficult to handle, such as repeated nullpointertions.

   If a captured exception is recorded, this problem cannot be encountered. In fact, unless you confirm that the exception has no effect on the rest of the code, at least make a record. To put it further, never ignore the problem. Otherwise, the risk is very high, which will lead to unpredictable consequences in the future.

2. Do not use overwriting Exception Handling Blocks

   Another dangerous processing is the overwriting processor (blanket handler ). The basic structure of the Code is as follows:

   1 try{2 // …3 }4 catch(Exception e){5 // …6 }

   There are two prerequisites for using a overwriting exception block:

   1. There is only one type of problem in the code.

   This may be true, but even so, we should not use overwriting exception handling to catch more specific exception forms, which are advantageous.

   2. A single recovery operation is always applicable.

   This is almost an absolute error. There is almost no way to deal with any problems.

   Analyze what will happen when the code is written in this way. Everything works as long as the method continuously throws the expected exception set. However, if an unexpected exception is thrown, the operation to be taken cannot be seen. When the overwriting processor executes the same job for the new exception class, the exception handling result can only be seen indirectly. If the Code does not print or record the statement, the result is not displayed at all.

   Even worse, when the code changes, the overwriting processor will continue to act on all new exception types and process all types in the same way.

3. Generally, do not convert a specific exception to a more common exception.

   An error occurs when a specific exception is converted to a more common exception. In general, this will cancel the context generated when the exception is thrown at the beginning, and it will be more difficult to process when the exception is passed to other locations of the system. See the following example:

   1 try{2 // Error-prone code3 }4 catch(IOException e){5 String msg = "If you didn ’ t have a problem before,you do now!";6 throw new Exception(msg);7 }

   Because there is no original exception information, the processor block cannot determine the cause of the problem and how to correct the problem.

4. Do not handle exceptions that can be avoided

   Some exception types do not need to be processed. Generally, runtime exceptions fall into this category. When dealing with null pointers or data indexes, you do not have to resort to exception handling.