Thoughts on exception throw and capture

Thoughts on Exception Handling

 

Java has two types of exceptions. I. Check exceptions. Ii. Non-checkable exceptions (runtime exceptions)

 

 

The difference between the two: Check exceptions must be explicitly try-catch or throw. You do not need to capture runtime exceptions.

There is no need for much discussion about checked exceptions because they must be captured (during design exceptions ). This article mainly discusses how to throw and capture runtime exceptions.

The correct capture and throw of running exceptions can make the system code more concise and RD only needs to be related to normal services, and exception handling is required for abnormal services.

 

Problems:

1. Every time you call another method, you must consider and analyze whether this method is abnormal and affects normal business processes.

2. In the business call chain, each method has a try-Catch Block, and the code structure is redundant, which is not conducive to maintenance. Every method captures and prints exceptions, resulting in duplicate logs or error messages, it is not conducive to precise problem locating.

3. In the business method call chain, a service result object is passed in the call link layer as the return value of the method, and normal results and abnormal results must be constructed. Return values sometimes cannot terminate the exception process quickly or correctly, and many return statement blocks are required.

 

An overall assumption in the Java Web structure is:

 

1. Capture exceptions and throw exceptions in basic methods (non-business methods). The basic methods are at the bottom of the call chain mainly in the Dao, util, daomian, and service layers, the basic method is not related to the business or process. The responsibility is relatively simple and there is an exception risk.

Database Operation: Example: 1. query a car dealer; 2. Save a refund .... Possible exceptions or errors: database connection timeout; excessive connections, index primary key conflict ...;

RPC remotely calls a third-party interface: Example: 1. Obtain the financial deposit interface; 2. Obtain the vehicle source information based on the carid. Possible exceptions or errors: connection times out, and the returned results parameters do not match ....

File IO operations:

Capture the exception of the basic method, print the error stack information (log), and throw an exception (runtime exception, which is easy for the caller to understand, rather than stack information) to end the service. That is, the log outputs the exception stack information for RD use, and throws an exception to end the service and outputs The frontend or call to understand the information.

The foundation method is equivalent to the Foundation. The foundation must be solid and complete.

 

2. perform business logic development at the controller, service, and domain layers. business logic development only focuses on normal processes and calls basic methods without capturing exceptions. An exception is thrown when a service exception occurs, and an understandable exception message and a detailed stack error message is output by log.

1. No exception capture. The basic method or other services are called, and the basic methods have been captured and converted. Therefore, no exception capture is required. Unless some exceptions do not affect the business or need to be caught or thrown out (for example, when a refund ticket is created, BD will be sent a notification to notify BD, and then BD will log in for processing. Failed notifications do not affect business processes. You can eat exceptions or capture and process exceptions ).

2. There are two main causes of exceptions in business methods: 1. Transfer the exception to call other methods. 2. Business exception (when the warranty is withdrawn, the user's deposit is less than 1000 ). In these cases, an exception is thrown directly to terminate the business and continue execution, instead of returning the returned value. If an exception occurs in the called method, it is not captured, because the calling method mainly involves the business method and basic method (the basic method has been processed), which is directly captured by the high-level.

The business method is equivalent to the internal space of the house. By default, the foundation is solid, and the external walls are isolated. How to Construct the internal space is your own business, and the external environment has no permission, So let go and focus on the business logic.

 

3. Global exception Capture: capture exceptions thrown by the business layer or uncaptured exceptions for unified processing and display them to the front end, instead of allowing the front end to see a 500 internal error.

The external global capture is equivalent to the exterior wall of the house. What you see outside is correct and handled, and you cannot see Internal flaws.

 

4. Custom exceptions can be divided into daoexception, domainexception, and serviceexception to facilitate the identification and identification of exceptions.

 

5. Use controlleradvice in spring boot to handle global exceptions. For exceptions in filters, execute them before AOP to redirect them to exceptioncontroller for processing.

 

Note:

1. Verify the parameters of business methods and call other methods. If the verification fails, an exception is thrown.

2. Exceptions thrown by services must be easy to understand, while logs must be detailed.

3. methods must be complete. Except for throwing an exception or calling other methods, there should be no unknown exception (that is, you cannot construct the method in the method body rather than throw an exception ), in short, you cannot write code that may have exceptions (such as null pointer exceptions ).

4. Exceptions cannot be eaten without processing. The content of the catch method body is empty.

5. Do not throw an exception in the loop.

6. Capture exceptions at a high level.

 

 

 

Thoughts on exception throw and capture