大家讲道理2017-04-17 16:44:05
我的設計通常是DAO層不處理任何異常，Service層呼叫DAO層並捕捉異常，然後透過一個狀態碼將資訊回傳給Action層。
個人覺得，Action層的邏輯盡量簡單些為好，因為Action是介面層，太複雜讓人難以一眼看穿介面要提供的功能。
伊谢尔伦2017-04-17 16:44:05
錯誤碼在過程導向的語言中非常常見，但是在物件導向的過程中，使用異常來處理多一點。
使用錯誤碼的缺點是：
1、對錯誤的檢測不是強制的
2、代碼充斥各種if else的錯誤碼判斷
使用異常的好處是：
1、對錯誤的檢測是強制的，你必須處理或上拋異常
2、程式碼不必對各種狀態碼進行判斷，有異常直接拋出終止往下運行
3、對於錯誤有堆疊可以追蹤。
黄舟2017-04-17 16:44:05
我覺得這主要看兩點：1各層的邏輯量的輕重，則需要你自己取捨；2個人風格，我比較喜歡能在業務層處理的盡量處理，但dao層只拋異常。其實哪裡處理都行，只要不直接回傳給客戶端就好。
阿神2017-04-17 16:44:05
業務層都是if else 基本上都是調用資料返回前應該設定預設值例如空值只有dao類別可能與業務層之外的系統互動,資料庫,網路出現異常的機率更大,所以應該在dao類別裡面妥善處理異常業務層/ action傳回空值/缺省值這樣對使用者比較友善
怪我咯2017-04-17 16:44:05
持久化這塊一般不進行邏輯處理，往上一級拋最好，不然以後要改用一些持久化框架了移植起來太麻煩
雖然造成異常的情況有很多，但對用戶的結果來說就是沒成功，至於為什麼沒成功是留給開發人員看的，所以我認為不用返回這麼多結果，直接返回異常開發人員通過查看哪種異常也能判斷原因
我想你要記錄這個應該是用來判斷如果出錯了是哪裡出錯是吧，列印日誌應該是一個挺普遍的做法，把異常之類的加入到日誌裡
迷茫2017-04-17 16:44:05
嵌套了多少層？
先學會減少巢狀吧
另外service層就是回傳確定的結果，它就是處理異常和業務邏輯的
action層起到路由的作用，呼叫該調的service直接回傳就好
PHP中文网2017-04-17 16:44:05
你這個例子無所謂，
但是存在事物的情況下，就有所謂了，
如果你使用的是申明式事物，那麼事務中的某一個中間環節出錯，因為錯誤直接拋出，所以可以在事務開啟的那一層被catch到，並回滾當前事務中所有的操作，
如果你在dao曾捕獲了異常，那麼感知這個業務是否需要回滾就變得很麻煩，需要對每一個dao操作結果進行判斷。