Talking about the return format in the log, encapsulation format handling, exception handling

Don't talk about model selection , The main consideration is info Level of data ：

General information ：

As a general rule , We all encapsulate a return exception class on the project , Used to pack information .
Generally speaking, it is return code and return information , This is the most common .
In order to better check the problem , We designed it as follows ：
000000- Business success
000001- Business failure, etc

about Msg Information? ：
We can define the information format ： Or information tips .
In this way, the corresponding packaging information can be output in different process information .
The information should have rules , Such as XX, reason , Easy to go online grep Search for

Generally, this is ok .

exception handling ：

We know the level of exceptions ：

We can define our own exception class , It's not commonly used , But you can do this .
It's more about exceptions provided by the framework ：
Spring MVC There are the following 3 A way to handle exceptions ：

Use Spring MVC The simple exception handler provided SimpleMappingExceptionResolver.
Realization Spring Exception handling interface HandlerExceptionResolver, Customize your own exception handler .
Use @ExceptionHandler Annotation implements exception handling

Inherit exceptions directly from the framework and handle . that will do .

Processing mode ：

Direct selling , Leave it to the system .
Catch exceptions by yourself and handle .

1. Exception handling Basics
   1.1 System.out.println It's expensive . call System.out.println Will reduce system throughput .

   1.2 Don't use abnormal printStackTrace() Method .printStackTrace By default, the call stack will be printed on the console , Accessing the console in a production environment is unrealistic .

2. Basic principles of exception handling
   2.1 If you can't handle exceptions , Do not catch this exception .

   2.2 If you want to capture , It should be caught near the source of the divorce .

   2.3 Don't swallow the anomalies you catch .
   *（ Is the exception caught , But do nothing ）

   2.4 Unless you want to throw an exception again , Otherwise, take it. log get up .

   2.5 When an exception is repackaged , And then throw it again , Do not print statck trace.

   2.6 Use custom exception classes , Don't throw an exception every time you need to throw it java.lang.Exception. Method callers can use throws Know what exceptions need to be handled – So it is self describing .

   2.7 If you write business logic , For errors that end users cannot fix , The system should throw non checked exceptions （unchecked exception）; If you write a third-party package for other developers , For irreparable errors, use exceptions that need to be checked （checked exception）.

   2.8 Never write because throws Sentences will make you uncomfortable to use , Without declaring the exceptions that need to be checked .

   2.9 Application level errors or irreparable system exceptions use non checked exceptions （unchecked exception） Throw out .
   *（ Attention is wrong , Means irreparable , For example, the configuration file is wrong ）

   2.10 Organize your methods according to the granularity of exceptions

In short ：log Printing exception ,, Custom exception , Pay attention to the detected abnormality .
Generally, you can print , The system has defaulted to exception .

Recommended reading ：
https://www.cnblogs.com/langtianya/p/6931190.html