Shulou(Shulou.com)06/01 Report--

This article mainly introduces the controller exception handling and service layer transaction control method related knowledge, the content is detailed and easy to understand, the operation is simple and fast, has a certain reference value, I believe that everyone after reading this controller exception handling and service layer transaction control method article will have a harvest, let's take a look.

Controller exception handling and transaction Control of service layer

Recently, writing code involves some transactions, and I finally straightened out the code in the morning. I didn't know where to do exception handling before, resulting in code try-catch all over the place, which is quite ugly.

Or write code based on the three layers of controller-service-dao. From the entrance, the method of the controller layer corresponds to a certain url, which is for the application staff, and should return information that they can understand. Therefore, controller must do exception handling. Generally speaking, there will be a unified exception handling method.

The service layer is oriented to some methods in the controller,service layer, and its transactions must be guaranteed, so transaction control in the service layer is quite necessary. For multiple sql, if the execution of a sql fails, then the sql statements that have been executed should be rolled back.

The dao layer is more of a single sql statement, so there is no need for transaction control, because the transaction overhead is not cheap (official words)

Based on the above three points, let's go back and think about the handling of exceptions. In general, we should throw the exception on the Internet and throw it all the way to the final handling layer. Therefore, it is not necessary to try-catch the dao layer and service, just throw the exception up.

Corresponding to this is the transaction configuration of spring. By default, spring only rolls back runtime exceptions. If exceptions are handled in the dao layer, additional configuration is required before spring rolls back exceptions. The common configuration is @ Transactional (rollbackFor=Exception.class).

By the way, a java knowledge point. With regard to the role of finally in try-catch-finally, finally was designed to close resources. If you use the include statement in finally, it will overwrite the return value of try or catch. The most common thing is to overwrite the exception. Even if the catch throws an exception, it will be overwritten and return the return value of the return statement in finally.

Controller layer Exception abnormal transaction rollback failure problem Spring's @ Transactional source code says

By default, a transaction will be rolling back on {@ link RuntimeException} and {@ link Error} but not on checked exceptions (business exceptions).

By default, if an unchecked exception (an exception inherited from RuntimeException) or Error is thrown in a transaction, Spring rolls back the transaction; otherwise, Spring does not roll back the transaction.

Test ①

The default spring transaction is rolled back only when an uncaptured RuntimeException occurs.

/ / Test rollback success case based on IllegalArgumentException (RuntimeException) rollback @ GetMapping ("/ testSuccess") @ Transactional// if not added, public R testSuccess (@ RequestParam ("type") Integer type) {eduTeacherService.removeById ("2"); if (type = = 1) {throw new IllegalArgumentException ("Test rollback success case!");} eduTeacherService.removeById ("3"); return R.ok ();}

Test ②

Exception exception, transaction rollback failed

/ / Test rollback failure case, rollback based on Exception @ GetMapping ("/ testFail") @ Transactionalpublic R testFail (@ RequestParam ("type") Integer type) {try {eduTeacherService.removeById ("2"); if (type = = 1) {throw new Exception ("Test rollback failure case!");} eduTeacherService.removeById ("3");} catch (Exception e) {e.printStackTrace ();} return R.ok ();}

Test ③

Using rollbackFor to solve Exception without transaction rollback

RollbackFor = Exception.class + throws Exception@GetMapping ("/ testFailRollbackFor") / / configure rollbackFor@Transactional (propagation= Propagation.REQUIRED,rollbackFor = Exception.class) public R testFailRollbackFor (@ RequestParam ("type") Integer type) throws Exception {eduTeacherService.removeById ("2"); if (type = = 1) {throw new Exception ("Test rollback failed rollbackFor success case!");} eduTeacherService.removeById ("3"); return R.ok ();}

Test ④

Manual rollback resolution Exception does not perform transaction rollback

Catch:TransactionAspectSupport.currentTransactionStatus (). SetRollbackOnly (); @ GetMapping ("/ testSuccessByHand") @ Transactionalpublic R testSuccessByHand (@ RequestParam ("type") Integer type) {try {eduTeacherService.removeById ("2"); if (type = = 1) {throw new Exception ("Test rollback failure case!");} eduTeacherService.removeById ("3");} catch (Exception e) {e.printStackTrace () / / Manual rollback. If sql2 () throws an exception, sql1 () will roll back without affecting the normal execution of TransactionAspectSupport.currentTransactionStatus () .setRollbackOnly ();} return R.ok ();}

This is the end of this article on "exception handling of controller and transaction control methods of service layer". Thank you for reading! I believe you all have some knowledge of "exception handling of controller and transaction control methods of service layer". If you want to learn more, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.