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里請大家幫忙看看
4 回答
泛舟湖上清波郎朗
TA貢獻1818條經驗 獲得超3個贊
問題：上面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里"，想法沒有錯，但真的在海量日志里處理過錯誤信息的人是會有體會的。明明可以統一處理，卻沒做，這算是設計缺陷或者失誤。不是解決問題最有效的方案
我是外行，輕點拍磚^^
RISEBY
TA貢獻1856條經驗 獲得超5個贊
使用Spring AOP對異常進行統一處理，當然是第三種方法更好了。使用Spring AOP對serivce層拋出的異常進行攔截，記錄所有未處理的異常日志，并將所有未處理異常轉換成統一自定義的系統異常，以便讓controller層或Rpc層能夠將這些自定義的異常信息反饋到前端，在瀏覽器端進行展示。
不要忘了，使用Spring AOP對異常進行攔截，其真正作用是實現：將異常的處理邏輯和正常的處理邏輯進行解耦。所以你說異常的粒度控制在什么級別？這個是根據你的業務邏輯來的。諸如，操作數據庫增刪改查失??？調用外部接口失敗？其他異常信息等等。
你們公司的方式是不規范的，不合適的。處理日志時，需要在每一個try-catch塊包含一些處理代碼，有時候異常處理的代碼比正常執行代碼還多，污染正常執行代碼。 異常處理代碼散落，修改起來時非常麻煩。無法對某些異常進行統一處理和修改。
Service中的業務方法命名不按照事前定義好的規則進行命名的話，AOP是攔截不到的。也就是說事務控制是無法加載的。這些命名的規范什么的需要在配置文件中指定。
夢里花落0921
TA貢獻1772條經驗 獲得超6個贊
我們都是在controller層做aop異常處理的
異常分為非ajax異常和ajax異常, 因為我們是使用jquery,沒有做到前后端完全分離,有的前端數據是后端直接渲染
ajax異常: 在header中包含X-Requested-With來判斷
非ajax異常: ajax異常之外的
肯定你前臺顯示給客戶錯誤的方式是不同的, 所以在Interceptor(filter)(aop)中分別處理
在service類的每個方法中, 沒有說整個用try catch包住的, 太二了,異常分為你控制不了的比如數據庫異常,空指針什么的, 這些都不用catch的, 在service中是根據業務中的異常業務拋出, 比如用戶名重復了, 我就throw 一個BizException("用戶名重復"),其中BizException是繼承了RuntimeException的
lz說的aop來處理異常, 我不知道你是在service層還是controller層, 顯然按照我上面的分析應該是在controller層做的
如果我這個不是最佳答案,就太沒天理了
添加回答
舉報
0/150
提交
取消