My design is generally that the DAO layer does not handle any exceptions. The Service layer calls the DAO layer and catches the exception, and then returns the information to the Action layer through a status code. Personally, I feel that the logic of the Action layer should be as simple as possible, because Action is the interface layer, and it is too complicated to see through the functions provided by the interface at a glance.
Error codes are very common in procedural languages, but in object-oriented procedures, exceptions are used to handle them a little more. The disadvantages of using error codes are: 1. Error detection is not mandatory 2. The code is full of various if else error code judgments The advantages of using exceptions are: 1. Error detection is mandatory, you Exceptions must be handled or thrown up 2. The code does not need to judge various status codes. If there is an exception, it will be thrown directly and terminate the operation. 3. There is a stack for tracking errors.
I think this mainly depends on two points: 1. The amount of logic in each layer needs to be chosen by yourself; 2. Personal style, I prefer to handle it as much as possible in the business layer, but the dao layer only throws exceptions. In fact, it can be processed anywhere, as long as it is not returned directly to the client.
The business layer is all if else. Basically, the default value should be set before returning the data, such as null value. Only the dao class may interact with systems other than the business layer. The probability of abnormality in the database and network is greater, so it should be in the dao class. Properly handle exceptions in the business layer/action and return null/default values, which is more user-friendly
Persistence is generally not logically processed. It is best to throw it to the upper level, otherwise you will have to use some persistence framework in the future. It will be too troublesome to transplant. Although there are many situations that cause exceptions, the results for users are It was not successful. As for why it was not successful, it is left to the developers to see, so I think there is no need to return so many results and directly return the exception. The developer can also judge the cause by looking at which exception I think you should record this for Determine what went wrong if something went wrong, right? Printing logs should be a common practice, and add exceptions and the like to the logs
How many levels are nested? Learn to reduce nesting first
In addition, the service layer returns a certain result. It handles exceptions and business logic. The action layer plays the role of routing. Just call the service and return it directly.
It doesn’t matter in your example, But when there are things, it does matter. If you are using declarative things, then an error occurs in an intermediate link in the transaction, because the error is thrown directly, so you can start the transaction That layer is caught and rolls back all operations in the current transaction. If you have caught an exception in dao, then it will be very troublesome to sense whether the business needs to be rolled back. You need to perform the results of each dao operation. judge.
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
My design is generally that the DAO layer does not handle any exceptions. The Service layer calls the DAO layer and catches the exception, and then returns the information to the Action layer through a status code.
Personally, I feel that the logic of the Action layer should be as simple as possible, because Action is the interface layer, and it is too complicated to see through the functions provided by the interface at a glance.
Error codes are very common in procedural languages, but in object-oriented procedures, exceptions are used to handle them a little more.
The disadvantages of using error codes are:
1. Error detection is not mandatory
2. The code is full of various if else error code judgments
The advantages of using exceptions are:
1. Error detection is mandatory, you Exceptions must be handled or thrown up
2. The code does not need to judge various status codes. If there is an exception, it will be thrown directly and terminate the operation. 3. There is a stack for tracking errors.
The library throws an exception and the business returns an error code.
I think this mainly depends on two points: 1. The amount of logic in each layer needs to be chosen by yourself; 2. Personal style, I prefer to handle it as much as possible in the business layer, but the dao layer only throws exceptions. In fact, it can be processed anywhere, as long as it is not returned directly to the client.
The business layer is all if else. Basically, the default value should be set before returning the data, such as null value. Only the dao class may interact with systems other than the business layer. The probability of abnormality in the database and network is greater, so it should be in the dao class. Properly handle exceptions in the business layer/action and return null/default values, which is more user-friendly
Persistence is generally not logically processed. It is best to throw it to the upper level, otherwise you will have to use some persistence framework in the future. It will be too troublesome to transplant.
Although there are many situations that cause exceptions, the results for users are It was not successful. As for why it was not successful, it is left to the developers to see, so I think there is no need to return so many results and directly return the exception. The developer can also judge the cause by looking at which exception
I think you should record this for Determine what went wrong if something went wrong, right? Printing logs should be a common practice, and add exceptions and the like to the logs
How many levels are nested?
Learn to reduce nesting first
In addition, the service layer returns a certain result. It handles exceptions and business logic.
The action layer plays the role of routing. Just call the service and return it directly.
I asked this question on Zhihu: https://www.zhihu.com/question/36278363
Please refer to it.
It doesn’t matter in your example,
But when there are things, it does matter.
If you are using declarative things, then an error occurs in an intermediate link in the transaction, because the error is thrown directly, so you can start the transaction That layer is caught and rolls back all operations in the current transaction.
If you have caught an exception in dao, then it will be very troublesome to sense whether the business needs to be rolled back. You need to perform the results of each dao operation. judge.