Fundamentals and Basic principles of Java exception handling

Today, when looking at the Hadoop source code, think about the system that you have been doing recently, found that many of the methods of exception handling is not correct, or according to the traditional exception handling (that is, using the return value to identify the exception of the program). Many of the methods in Hadoop are declared with exceptions, and many of the methods in my system are declared without throwing exceptions. Only the exception was judged and the error message was output, but no exception was thrown.

The ReadFields () method of the Block class under the Org.apache.hadoop.hdfs.protocol package:

public void ReadFields (Datainput in) throws IOException {    this.blockid = In.readlong ();    This.numbytes = In.readlong ();    This.generationstamp = In.readlong ();    if (NumBytes < 0) {      throw new IOException ("Unexpected block size:" + numbytes);//Throws an exception, if it is not thrown, but only System.out.pri Ntln error prompt,    }

1. If there is a throws exception inside the method declaration name, the method body can not throw an exception. Because the exception description can be included in the method declaration, it is not actually thrown! The advantage of this is that you take a position for the exception before you can throw the exception without modifying the existing code. This ability is important when defining abstract base classes and interfaces so that derived classes or interface implementation classes can throw these pre-declared exceptions.

2. Why is there no throws in the method declaration, but the method body throws an exception? Exceptions inherited from RuntimeException can be thrown without exception description throws! For runtime exceptions (also known as non-checked exceptions unchecked exception), the compiler does not require an exception description. Exceptions of type runtimeexception (and its subclasses) can only be ignored in code, and the handling of other types of exceptions is enforced by the compiler. The reason for this is that RuntimeException represents a programming error.

3. Runtime exceptions are automatically thrown by Java virtual machines!

1. Exception handling Base
   1.1 System.out.println is a high price. Calling SYSTEM.OUT.PRINTLN can reduce system throughput.

   1.2 Do not use the exception Printstacktrace () method in the production environment. Printstacktrace The call stack is printed to the console by default, and accessing the console in a production environment is unrealistic.

2. Exception handling Basic Principles
   2.1 If you cannot handle the exception, do not catch the exception.

   2.2 If you want to capture it, you should capture it near the source of the exception.

   2.3 Do not swallow the exception you caught.
   * (is the catch exception, but do nothing)

   2.4 Unless you want to re-throw the exception, log it up.

   2.5 Do not print STATCK trace when an exception is repackaged and then re-thrown.

   2.6 With a custom exception class, do not throw java.lang.Exception every time you need to throw an exception. The caller of the method can know what exceptions need to be handled by throws-so it is self-describing.

   2.7 If you write business logic, the system should throw a non-checked exception for errors that the end user cannot fix (unchecked exception); If you write a third-party package to other developers, For uncorrectable errors, use the exception that you want to check (checked exception).

   2.8 Never make it uncomfortable for you to write throws statements without declaring the exceptions you need to check.

   2.9 Application-level errors or uncorrectable system exceptions are thrown with non-checked exceptions (unchecked exception).
   * (Note that it is an error, which means it is not repairable, such as a profile error)

   2.10 Organize your method based on the granularity of the exception