Exception handling

1. [Mandatory] Do not catch runtime exception classes defined in the Java class library that inherit from RuntimeException, such as: IndexOutOfBoundsException / NullPointerException. Such exceptions are avoided by programmers' pre-check , to ensure program robustness.

Positive example: if(obj != null) {...}

Counter example: try { obj.method( ) } catch(NullPointerException e){...}

2. [Mandatory] Do not use exceptions for process control or conditional control, because the processing efficiency of exceptions is lower than that of conditional branches.

3. [Mandatory] Try - catch a large section of code, which is irresponsible. When catching, please distinguish between stable code and non-stable code. Stable code refers to code that will not go wrong no matter what. For catches of unstable code, try to distinguish exception types as much as possible, and then handle the corresponding exceptions.

4. [Mandatory] The purpose of catching an exception is to handle it. Don't catch it and discard it without processing anything. If you don't want to handle it, please

throw the exception to its caller. By. The outermost business user must handle exceptions and convert them into content that users can understand.

5. [Mandatory] Put a try block in the transaction code. After catching the exception, if you need to roll back the transaction, you must pay attention to manually

rolling back the transaction.

6. [Mandatory] The finally block must close the resource object and stream object, and try-catch if there is an exception.

Note: If JDK 7, you can use try - with - resources method.

7. [Mandatory] Return cannot be used in the finally block. After the return in the finally block returns, the method ends execution, and

will not execute the return statement in the try block again.

8. [Mandatory] Catching exceptions and throwing exceptions must match exactly, or the catching exception must be the parent class of the throwing exception.

Note: If the opponent is expected to throw a hydrangea ball but actually receives a shot put, an unexpected situation will occur.

9. [Recommendation] The return value of the method can be null. It is not mandatory to return an empty collection or an empty object. You must add comments to fully

explain under what circumstances a null value will be returned. The caller needs to perform null judgment to prevent NPE problems.

Note: This specification clearly states that preventing NPE is the caller's responsibility. Even if the called method returns an empty collection or empty object, the caller will not be able to sit back and relax, and must take into account the situation of remote call failure, runtime exception and other scenarios where null is returned. 10. [Recommendation] Preventing NPE is the basic training of programmers. Pay attention to the scenarios where NPE occurs:

1) The return type is a packed data type, which may be null. When returning an int value, pay attention to the null test.

Counter example: public int f() { return Integer object}; If it is null, it will automatically unbox and throw NPE.

2) The query result of the database may be null.

3) Even if the elements in the collection are NotEmpty, the retrieved data elements may be null.

4) NPE judgment is always required for objects returned by remote calls.

5) For the data obtained in Session, it is recommended to check NPE to avoid null pointers.

6) Cascading calls obj . getA() . getB() . getC(); A series of calls can easily cause NPE.

11. [Recommendation] Whether to use "throw exception" or "return error code" in the code, for http/api open interfaces outside the company must use "error code"; and exceptions are recommended within the application Throw; For cross-application RPC calls, the Result method is preferred, and isSuccess, "error code", and "error brief information" are installed.

Explanation:

Reasons for using Result method for RPC method return: 1) Use the exception return method. If the caller does not catch it, it will A runtime error occurs.

2) If you do not add stack information, just new custom exceptions, and add your own understanding of the error message, it will not be of much help to the calling

end to solve the problem. If stack information is added, in the case of frequent call errors, the performance loss of data serialization and transmission is also a problem.

12. [Recommended] Distinguish unchecked/checked exceptions when defining, avoid using RuntimeException to throw directly, is not allowed to throw Exception or Throwable, and use custom exceptions with business meaning. . We recommend custom exceptions that have been defined in the industry, such as: DAOException / ServiceException, etc.

13. [Reference] Avoid duplicate code (Don’t Repeat Yourself), that is, the DRY principle. Note: Copying and pasting code at will will inevitably lead to duplication of code. When modification is needed in the future, all copies

need to be modified, which is easy to miss. Extract common methods, abstract public classes, or even shared modules when necessary.

Positive example: There are multiple public methods in a class, and they all need to perform several rows of the same parameter verification operations. At this time, please extract: private boolean checkParam(DTO dto){...}