The misunderstanding and experience summary of Java exception handling

Anomaly detection anomaly and non-detection anomaly , the application scenario can be summarized as follows:

• The calling code cannot continue execution and needs to be terminated immediately. There are too many possibilities for this, such as server connections, incorrect parameters, and so on. This applies to non-detection exceptions, does not require explicit capture and processing of the calling code, and the code is straightforward.
• The calling code requires further processing and recovery . If SQLException is defined as a non-detection exception, the developer takes the data for granted that the SQLException does not require explicit capture and processing of the calling code, which in turn leads to serious Connection not shutting down, Transaction not rolling back, DB such as dirty data in the SQLException is defined as a detection exception that drives the developer to explicitly capture and cleans up resources after the code generates an exception. Of course, after cleaning up the resources, you can continue to throw non-detection exceptions to prevent the execution of the program. Based on observation and understanding, detection anomalies can be applied to tool classes in most cases.

Two do not display the exception directly on the page or the client

　　Any exception has no practical significance, the vast majority of customers do not understand the abnormal information, software development should try to avoid the exception directly to the user.

III Do not use an exception to pollute the hierarchy of code

 Public Throw  // query database by ID }

From the design coupling point of view, here the SQLException pollution to the upper calling code, the call layer needs to explicitly use the Try-catch capture, or further to the upper-level throw. According to the design isolation principle, we can modify it appropriately to:

 public   Customer Retrievecustomerbyid (Long ID) { try  { //  query database by ID  }  catch   (SQLException e) { //  detect exceptions with non-detection exception encapsulation, lower hierarchical coupling  throw new   RuntimeException (Sqlerrorcode, E);  finally  { //  Close connection, clean up resources  }}  

Four do not ignore exceptions

 Public void Retrieveobjectbyid (Long id) {   try{       //... Some code that throws SQLException    }catch(SQLException ex) {     / * * * * Everyone       knows that the exception print here is meaningless, just output the error stack to the console.       * In the Production environment, the error stack needs to be output to the log.       * And after the catch is processed, the program continues to execute, causing further problems */           ex.printstacktrace ();     }}

exception handling simply outputs an exception to the console, without any meaning. And there's an exception here that doesn't interrupt the program, and the calling code continues execution, causing more exceptions.

 public  void   Retrieveobjectbyid (Long id) { try  { // . Some code that throws SQLException  }  catch   (SQLException ex) { throw  new  runtimeexception ("Exception in   Retieveobjectbyid", ex);  finally  { // clean up resultset, statement, connection etc  }}  

Five do not include an exception in a loop statement

Exception handling consumes system resources

 for (int i=0; i<; i++) {    try{    }catch (xxxexception e) {         //...    }}

Six do not use exception to capture all potential exceptions

　　This does not need to repeat, exception too general, should catch specific anomalies.

Seven don't print the same exception at multiple levels

The same exception will be printed 2 times. If the level is a little more complicated, not to consider the performance of the print log consumption of the system, only in the Exception log to locate the exception specific problems have enough headaches.

　　in fact, the print log only needs to capture print on the outermost layer of the code, and exception printing can also be written as AOP, woven into the outermost layer of the frame.

Eight exceptions contain the information to be able to adequately locate the problem

Nine to consider possible potential exceptions, consider exceptions in your code

Ten finally in the resource cleanup and other related work

11 Make sure to add a @throws declaration in Javadoc and describe the exceptions that might result.

12 exception if there is a secondary relationship

　　The specific exception is unloaded in front, abstract in the back.

12 Package Exceptions

Sometimes it is better to catch a standard exception and encapsulate it in a custom exception. A typical example of such an exception is an application or framework-specific business exception. This allows you to add additional information, and you can also implement a special processing for the exception class.

 Public void wrapexception (String input) throws mybusinessexception {    try  {        // do Something    catch  (NumberFormatException e) {        throwNew Mybusinessexception ("A message that describes the error. " , E);}    }

The misunderstanding and experience summary of Java exception handling