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