推 POSIX:這篇怎麼沒人推 講的好清楚誒!!! 01/07 06:07
※ 引述《QQ29 (我愛阿蓉)》之銘言：
: ※ 引述《littleshan (我要加入劍道社!)》之銘言：
: : 我好奇一件事
: : 如果你們已經用 exception 來處理 error
: : 那為什麼還要 return error code?
: : 莫非你們呼叫了會使用 exception 的 library
: : 但自己寫的程式碼還在用 error code?
: : (雖然有時候不得不做這種蠢事...但能免則免吧)
: 其實我的腳色有點像是wrap API
: 例如SaveFile(....)這API我來寫...
: l 大 意思是說
: 我這邊就大膽的寫CreateFile
: WriteFile等等
: 出了錯
: 上層(稱為主程式好了)
: 主程式要知道 我這邊不是安全的他要知道該try catch起來這樣?
如果你統一用exception
那主程式的確要籍由 try/catch 來了解下層是否正確執行
: 所以我這邊就void 也不用return error code之類的嗎?
: 我現在常常是寫成
: try{
: do something that might cause exception
: return xxx<==也許是E_SUCCESS 或是 true
: }
: catch(..)
: {
: //印log
: //看看可否recover
: return xxx<==error code或是false;
: }
: 這種寫法我也沒特別查書籍或是資料說有沒有問題
: 單純就是自己覺得這樣寫OK
這樣寫的問題在於
呼叫你的上層收到的是 error code
而不是 exception object
為什麼傳遞 exception object 比較好？
因為：1. exception object 是自訂型別，可以容納更完整的錯誤資訊
2. catch 可以指定型別，讓你只針對某些型別進行錯誤處理，
讓你可以把處理錯誤的程式碼寫得很乾淨易懂
改寫方法很簡單：如果你可以處理，就在 catch 中把它處理掉 (recover)
不然就直接 rethrow 讓上層收到這個 exception
: 我自己是覺得 主程式能不handle就不handle exception
: 我來幫她處理
: 若有問題 他直接可以從error code去判斷要幹嘛
第三個 exception object 的優點
主程式如果無視 error code
程式依然會假裝正常地跑下去 (但結果一定不會是你想要的那樣)
但若 exception 發生而且主程式沒有 catch
會直接中止程式執行
: 而且常常聽到try catch好像會有效能上考量....
: 但原因是為啥我其實不清楚 才怕說濫用try catch會不會有問題
丟 exception 比回傳 error code 慢得多
但一般來說 exception 之所以叫例外，正是因為它很少發生
既然它會發生的機率不高，慢一點也是可以接受的
: : 統一用 exception 那你就可以大膽寫 void 了
: : caller 要知道成不成功，就請他自己去try/catch
: l大所說的統一用exception意思是 我出問題 就throw?
: 主程式完全要溝通好說 你要用我的API 一定要try catch起來保險?
: 我這邊就完全不處理 error case直接往上報?
: 但這樣會不會造成主程式要處理太多事情 (感覺就是我這邊包的太淺)
不是不處理
如果你知道要怎麼處理錯誤 (比如說寫入log)
那就自行處理就好
如果不知道怎麼處理才需要往上丟 exception
事實上
就算你用 error code
主程式也是要檢查回傳值 (相當於 try/catch)
否則造成的錯誤會更難找
: : 當然不是
: : 如果你知道錯誤要怎麼處理，那就要 catch
: : 你不知道怎麼處理的話，就不要 catch 讓 exception 往上傳遞
: : (不過有時候你需要 catch and rethrow 以避免資源洩露的問題)
: 我現在好像都是變成 catch and return error code而不是rethrow...
: 如果上層要再用try catch包一次的話 會不會造成效能的差異呢?
: 謝謝
會啊
不過就如前面說的
exception 主要用在異常現象發生的時候
合理使用的話對整體的效能影響並不會太大
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 114.32.15.163