If the operation fails, just return normally. Return the error code of the operation failure, such as
success:false,
message:更新/删除失败
But as a development principle, the specific information of failure cannot be output to the user operation interface,
For example, if you update a piece of data and the update fails, it is because the database connection failed, the database hung up, etc. It is impossible for you to output the error message to the user and tell the user that the database connection failed
If it is a SQL error, it is an application error. Be sure to catch the exception and record the exception in the log
You must use try{}catch(){} for SQL-related operations. You must not flow exceptions to the upstream, and the upstream does not perform operations related to exception handling
Of course, find all the exceptions caught, such as unique nicknames, incorrect passwords, etc. Return unknown exceptions for other exceptions, and don’t expose your own exception information.
On-site restore: Data is rolled back to before the operation. Whether to retry depends on the scenario. The general principle is to do synchronous retry and asynchronous retry
Exception handling: Synchronization: Exceptions are packaged into readable error messages to the user, reminding the user to try again. Asynchronous: Monitor abnormal information
If the operation fails, just return normally. Return the error code of the operation failure, such as
But as a development principle, the specific information of failure cannot be output to the user operation interface,
For example, if you update a piece of data and the update fails, it is because the database connection failed, the database hung up, etc. It is impossible for you to output the error message to the user and tell the user that the database connection failed
If it is a SQL error, it is an application error. Be sure to catch the exception and record the exception in the log
You must use try{}catch(){} for SQL-related operations. You must not flow exceptions to the upstream, and the upstream does not perform operations related to exception handling
Be sure to do a good job in batch operations,
Of course, find all the exceptions caught, such as unique nicknames, incorrect passwords, etc.
Return unknown exceptions for other exceptions, and don’t expose your own exception information.
Return information to the user based on the error code. It is not recommended to execute it again because it may cause dirty data to the database
On-site restore: Data is rolled back to before the operation. Whether to retry depends on the scenario. The general principle is to do synchronous retry and asynchronous retry
Exception handling: Synchronization: Exceptions are packaged into readable error messages to the user, reminding the user to try again. Asynchronous: Monitor abnormal information