javaWeb项目使用aop处理异常？
问题描述
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里
请大家帮忙看看
谢邀！ 不过我得声明我不是专家|_|
问题：上面1,2,3我对dao层，service层的方法处理是否合理。2,3哪种更好些？
首先我赞同你在1, 2, 3步里的分析和理解。其次，我认为3的处理更为妥帖，因为service层就已经不是纯粹的数据交互，而是包含了一系列业务逻辑的操作，通过捕获Throwable然后再抛出更有意义的(能准确描述错误的)异常，无论是记入日志还是事物处理，这个对于后续可能存在的补救/错误排查更合适
4.接上面，这个自定义的业务异常的粒度要控制到什么级别？能否举个例子
粒度取决于需求，譬如你只想做回滚，那么只要能够定位到什么service错了对你来说就够了。但如果还希望进一步排查root cause，那是不是异常信息里再多一些关于源错误的描述更好些？
5.上面2，3 我都是用的aop统一处理异常。我看大部分人也推荐这么做。因为service层各个方法里catch里的逻辑大都相似。使用aop统一处理，好处是显而易见的。我想知道，有什么弊端吗？因为我发现公司项目几乎没有这么做的。都是直接try-catch，返回结果。要么就是上面2里提到的不捕获。出了异常反正可以记录在log里
首先谈你们公司为什么没那么做，这可能是历史原因，之前搭建框架的人对aop认识不足，或者把个人喜好带到了工作中导致选择了直接到处try catch(这种方式简单粗暴，最易掌握)，aop是算是一种设计范式，无论架构师还是程序员，要想熟练掌握并且运用自如还是需要学习成本的(这可能算是弊端吧)。如果你对原因感兴趣，最好找几个老资格同事私底下聊聊看，说不定好能套出些其他内幕^^
关于"出了异常反正可以记录在log里"，想法没有错，但真的在海量日志里处理过错误信息的人是会有体会的。明明可以统一处理，却没做，这算是设计缺陷或者失误。不是解决问题最有效的方案
我是外行，轻点拍砖^^
这篇关于javaWeb项目使用aop处理异常？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
