1.dao层我是直接抛出异常,都是比较“底层”的异常,比如DataAccessException. 不捕获的原因是,假如service调用了多个dao方法,其中有一个发生了异常,如果该dao方法自己捕获了又没有重新抛出来。这时候,service事务没法回滚,因为它以为都执行正确了。
2.在service里, 调用的dao方法有可能抛出DataAccessException的话,那么service也不捕获。因为DataAccessException是runtime异常,无需强制try-catch,况且,如果你捕获了又没有抛出来,配置的事务没法感知到,因为默认只处理runtime异常,当然可以配置。
3.还可以这样,在service方法里,dao方法外面直接try-catch(Throwable e). 然后重新抛出自定义的业务相关的异常。比如TopicUpdateException.
问题:上面1,2,3我对dao层,service层的方法处理是否合理。2,3哪种更好些?为什么?
4.接上面,这个自定义的业务异常的粒度要控制到什么级别?能否举个例子
5.上面2,3 我都是用的aop统一处理异常。我看大部分人也推荐这么做。因为service层各个方法里catch里的逻辑大都相似。使用aop统一处理,好处是显而易见的。我想知道,有什么弊端吗?因为我发现公司项目几乎没有这么做的。都是直接try-catch,返回结果。要么就是上面2里提到的不捕获。出了异常反正可以记录在log里
请大家帮忙看看
泛舟湖上清波郎朗
RISEBY
梦里花落0921
胡说叔叔
相关分类