根据我在新项目中的经验，
1.不应该在DAO层处理异常。原因：通常我们把@Transactional注解放在服务层。因此我们需要回滚服务层的事务。如果你在DAO处理异常，那么它将不会回滚。跟随下面的链接了解为什么我们应该把@Transaction放在服务层。
Where should "@Transactional" be placed Service Layer or DAO
1.不应在服务层处理异常。原因：由于服务层执行多个DAO进行数据库操作，如果任何DAO失败，我们需要回滚事务。如果我们在服务中处理异常，那么我们可能不会回滚事务。有手动回滚事务的方法，但不建议使用。TransactionAspectSupport.currentTransactionStatus（）.setRollbackOnly（）;
因此，在控制器层处理异常。

您不能同时处理应用程序所有级别的异常;你必须考虑它们的上下文含义和你的应用程序的适当策略。2一些错误应该被忽略，一些应该被 Package ，一些应该被允许直接引发。
在spring-mvc应用程序中处理异常的一个方法是在适当的地方用你自己的库 Package 来自底层库的致命错误，以抛出它们的级别命名，例如ServiceException或RepositoryException。然后，一个@ControllerAdvice注解的类可以用@ErrorHandler注解的方法处理这些错误，并返回5XX http错误。
常见的应用程序错误，比如由于id不正确而导致实体未被找到，可能会导致自定义异常，例如NotFoundException被引发并随后在您的@ControllerAdvice注解类中被捕获。
这种技术的优点是在不同的应用程序层中有较少的错误处理代码，并且可以集中异常到响应的转换。
一个示例@ControllerAdvice注解类：

@ControllerAdvice
public class ErrorHandler extends ResponseEntityExceptionHandler {
    @ExceptionHandler({NotFoundException.class})
    protected ResponseEntity<Object> handleNotFound(RuntimeException e, WebRequest request) {
        return handleExceptionInternal(e, e.getMessage(),
                null,
                HttpStatus.NOT_FOUND, request);
    }

    @ExceptionHandler({ServiceException.class, RepositoryException.class})
    protected ResponseEntity<Object> handleInternalError(RuntimeException e, WebRequest request) {
        return handleExceptionInternal(e, e.getMessage(),
                null,
                HttpStatus.INTERNAL_SERVER_ERROR, request);
    }
}

您应该使服务具有事务性，并在控制器层处理异常：您可以选择基于控制器的异常处理（使用@ExceptionHandler）或全局异常处理（使用@ControllerAdvice类）。2在发生异常时，向用户显示一些信息（例如错误页面）可能比较实用。
您可以在Spring MVC here中找到异常处理的有用示例。