Java Exception Handling

An exception is a condition that prevents the current method or scope from continuing execution. Let the situation that cannot be performed or is not expected to be executed be discovered as soon as possible. The use of Java exception architectures can reduce the complexity of error code discovery and processing.

Java Anomaly System

Java all exceptions are inherited from Throwable, specifically divided into two categories, error and exception. Error is the case in which the program cannot recover itself. such as OUTOMEMORYERROR,JVM crashes and so on. Exception can handle the recovery of the normal state after the program is fetched properly, without the program stopping. But although runtimeexception can crawl but on the client side, can do things very limited, can only be discarded directly. So exception can be divided into checked exception and unchecked Exceptions. The hierarchy diagram is shown below.

Exception Handling Ideas:

The core idea of processing is to convert the exception into checked or unchecked. Unchecked case the exception client does not need to know or even throw it, it can not do anything, such as SqlException, it should be processed on the server, and should not be thrown to the client, even if thrown to the client, the client is usually unable to process. While the checked exception needs to be handled by the client, such as the FileNotFoundException client needs to know that the file is not found, the client can solve the problem by other means, such as replacing other paths.

When handling exceptions, you should remember a word: "Can the client take any action on the exception?" "If measures can be taken, they should be converted to checked and thrown to the client." Otherwise convert it to unchecked in-place processing, such as a print error log.

Exception Handling Best Practices

• for caught exceptions, you should not normally ignore the

   catch   ( Nosuchmethodexception e) { return  null   

  The

  Fetches the exception but does not do anything, unless you are sure that the exception can be ignored, otherwise you should not do so. This causes the outside to be unaware that the method has an error and cannot determine the reason for locating the error.

• use more specific exception types

   public  void  foo () Span style= "color: #0000ff;" >throws   Exception {}  try   {SomeMethod ();}  catch   (Exception e) {logger.error (  method has failed ", E);}  

  This is the case with the two code snippets above, either throwing an exception or fetching the exception should not use exception directly. This can result in two situations where exception cannot provide specific exception information, is not conducive to processing, and forces the client to handle (crawl) Some exceptions that do not require attention. The client calls the first piece of code needs to know is the specific exception, in order to have targeted processing, and some exception the client does not need to pay attention to. For the second piece of code, exception too broad, processing time can not know what is wrong, so there is no targeted processing, while it is possible to grab the exception is not handled at all, but because it is exception, can not filter.

• Cannot only extract error messages ignore errors other information such as stacks

  Catch (nosuchmethodexception e) {   thrownew myserviceexception ("Some Information:" + E.getmessage ()); }

  Because only the exception information is extracted, it becomes difficult to analyze the exception because the exception's final position cannot be located.

• Do not advocate that the exception to the log and throw it

  Catch (nosuchmethodexception e) {   logger.error ("Some Information", e);    Throw e;}

  This way the same error message can be printed in multiple places, and there is no benefit to this log redundancy. Only makes error analysis more cumbersome.

• Exceptions that can only be handled by catch

  Catch (nosuchmethodexception e) {   throw  e;}

  This kind of processing is meaningless, and it is not necessary to fetch exceptions that cannot be handled.

• For exceptions that you do not intend to handle, you can use the finally

  Try {  somemethod ();   finally {  cleanUp ();  }

  You can do this when you are sure that the exception that the SomeMethod method throws can be ignored. However, it should be noted that if the exception should not be ignored, and the cleanup method throws an exception, this processing will directly discard the exception thrown by SomeMethod, then the client will never know SomeMethod throws an exception.

• The exception that is thrown by the method should be related to it: An exception that should be thrown by a method that reads a file should be a file-read-related exception, rather than a top-level exception such as IllegalArgumentException or exception.

It's important to remember the principle of "throw early Catch late" (which throws an unusually lazy fetch exception earlier), which means that it should be thrown when an exception occurs and the crawl should be able to get enough information. In simple terms, the underlying method should throw more exceptions, and exceptions should be fetched more in the top-level code.

The exception to throw should be documented, @throws. The method should explicitly indicate the exception that was thrown and the exception that was thrown.

At the same time to pay attention to abnormal abuse, abnormal use is a cost, there are many cases we can determine the method execution by the return value, rather than throw an exception. For example, connecting to a third-party webservice fails, which is meaningless for the client, so use a return value to determine if the connection succeeds better.

Reference:

Http://www.cnblogs.com/chenssy/p/3438130.htmlhttp://www.onjava.com/pub/a/onjava/2003/11/19/exceptions.html? page=2https://www.javacodegeeks.com/2013/07/ Java-exception-handling-tutorial-with-examples-and-best-practices.html

Java Exception Handling