I am currently coding a spring-mvc (jsp) project with three layers (controller -> service -> dao) and I am wondering what is the correct way of handling expected exceptions from dao invocations (e.g trying to persist an User that already exists, if it exists then call the register view again with a message saying that the user already exists), at first I thought it would be a good idea to catch the exception in the dao (e.g DataIntegrityViolationException) and throw my arbitrary checked exception so then I can do an exception handler for it in the controller but I fear if I do this then I might have conflicts if I want to make my service methods @Transactional later on since spring won't know how to rollback the transaction.

If this is correct then I have two ideas:

1. try/catch DataAccessException in the controller when I invoke the service call userService.register(..)

2. Use something among the lines like userService.findByUsername(username) in the controller (which returns an Optional) and if its present I notify the user before even calling userService.register(..)

Also, our teacher emphasizes on following DDD behavior and trying to avoid leaking business logic in our controllers and I fear both of this solutions do that but I don't really know how to handle it otherwise.

CodePudding user response：

Spring already converts checked JDBC exceptions into more informative unchecked exceptions, which play well with service layer transactions. All your custom checked exceptions do is force you to type more. Spring gives you reasonable defaults, take advantage of them.

Create an exception handler. Spring has multiple ways to implement this, none of them involve writing catch blocks for exceptions in your controller.

Put the business logic in the service, not the controller. It seems like your findByUsername and register can be combined in one transactional service method.