Ali Java development manual for the development of abnormal log part, developed a detailed specification, specifically divided into three parts (1, error code; 2. Exception handling; 3, log protocol;) If strictly observed, the efficiency of bug handling and communication efficiency of problem handling can be greatly improved, as follows:

Error code

  • 1. Error code formulation principle: fast traceability, easy to remember, standardized communication.

  • 2. The error code is a string of five characters divided into two parts: the source of the error + the number of four digits. Interpretation: Error sources can be divided into A/B/C class,A represents the client error,B represents the system server error,C represents the invocation of A third party error; Please refer to Appendix 3 of the manual for details.

  • 3, the use of error codes to avoid arbitrary definition of new error codes; Interpretation: easy to cause version confusion, reduce the use value of error code itself;

  • 4. Error codes cannot be directly output to users as prompts. Interpretation: Users can’t read error codes, which degrades user experience;

Second, exception handling

  • 1. Runtimeexceptions that can be avoided by pre-checking should not be handled by catching,eg:NPE exceptions;

  • 2. Exceptions cannot be used for condition and process control;

  • 3. If an exception is caught, it must be handled. If it is not handled, the exception is thrown to its caller.

  • 4. In the transaction scenario, attention must be paid to the rollback of the transaction after the occurrence of exceptions;

  • 5. In the finally block, resources/streams must be closed, and exceptions must be try-catch; Interpretation: Java7 and above, using try statements with resources;

  • 6. Do not return in finally.

  • 7. Throwable must be used to intercept exceptions when calling RPC, binary packages, or methods related to dynamically generated classes. In case of a class conflict, the arbitration mechanism may cause the introduction of an unexpected version to cause the method signature of the class to be mismatched. The code is correct at compile time, but NoSuchMethodError will be raised at run time.

  • 8. Preventing NPE is the basic quality of programmers, and they must be familiar with the possible scenarios of NPE.

Three, log protocol

  • 1, the application can not directly use the log system Log4j/Logback API, to use SLF4J/JCL API, using the facade mode of the log framework, is conducive to maintenance and the log processing mode of each class unified;

  • 2. All log files should be saved for at least 15 days. Because some exceptions occur at weekly frequency, logs of the current day should be saved as application name. log in the/application name /logs directory.

  • 3. When logging output,string is directly concatenated using placeholders; Interpretation: Using placeholders is just a substitution action that can significantly improve performance;

  • 4. Ensure that additivity=false is set in log4j. XML to avoid repeated log printing and waste of storage space.

  • 5. Do not use system. out or system. err to output logs or make E. printStackTrace() print an exception stack in the production environment.

  • 6. The exception information should include two types of information: the scene information and the exception stack information. Throws upward if no, throw upward through keyword throws.