1樓：qin meng
這個是兩種錯誤處理方式，代表兩種思想。try catch假定大部分情況都可以work，一但出了什麼我不知道的問題我不負責處理，也不負責恢復，交給外層模組。
返回error型別就嚴謹的多，我知道出了什麼問題，我可以選擇怎麼恢復或者處理，當然也可以吧錯誤直接返回給外層模組由外層處理，這樣就跟try catch一樣了。
所以並不是error code就要求呼叫者處理一切錯誤，如果錯誤碼全域性統一的情況下，呼叫者一樣可以跟catch端那樣返回自己不關注的錯誤碼給外圍模組。
try catch不好的地方我覺得是，第一，不利於錯誤恢復和重試，catch後如果想在試一次必須goto，沒有的話就沒辦法了。第二，try catch是不可靜態推理的，多層的try catch巢狀後很難推斷異常處理路徑，這給debug帶來很大困難。
所以，個人覺得try catch雖然優雅但是並不是個好的風格，error code顯然嚴謹的多。
2樓：丟貓
返回錯誤型別哪能叫異常處理
try catch等於是continuation有兩條或者更多條分支，沒有catch分支就回到呼叫頂層退出執行
3樓：
返回錯誤型別。。。。你在說golang吧？
throw至少呼叫方不處理，能一層層向外傳遞，這是自動。而返回錯誤型別，唉，看golang滿屏的if err !=nil {}你就知道了，你如果忽略錯誤，找起錯誤來很蛋疼。
4樓：est
從運維，ops，擦屁股的角度來說，統一的catch可以被工具給hook捕獲起來集中處理。比如打到ELK或者sentry。
返回值？？呵呵呵。 。斜眼看golang。你們抖M喜歡人肉埋點就肉吧。
5樓：
乙個大型軟體專案，可模擬於乙個大型工廠。
大型工廠，對於安全問題，肯定是非常重視的。因此，就必要有乙個安全管理體系，有相關的安全管理機構、設施、人員、規章制度等。
顯然，在設計安全管理體系時，就必須根據實際的情況進行相應的設計和部署。根據具體的情況，可能當場即時處置（如果是個小問題，當場搞得定），也可能上報到安全管理機構或部門。
返回錯誤型別，其實沒有處置錯誤，只是說：」嘿！這裡有乙個錯誤！
」。當然，有時也處理不了，比如讀檔案時，檔案不存在。但是，總體上，返回錯誤型別是很難建立錯誤管理和處置體系的。
try/catch是一種工具，使團隊可以建立起專案的異常處置的體系。返回錯誤型別只相當於try/catch中的異常丟擲。而採用try/catch可以建立：
異常的當場捕獲、異常的當場即時處理、或者丟擲異常。
至於怎麼建立軟體專案的異常管理和處置體系，當然首先要吃透專案，透徹地理解專案。
至於效能，總是會有一些開銷的。
6樓：不辣的皮皮
是不是我理解問題不到位。。。
返回錯誤型別，不就是為了外層可以catch住麼？
不知道會錯成什麼型別，就會catch全部型別；否則可以單獨catch某一種型別，更加精準地處理。
7樓：irakih
這倆不是versus關係吧，不管題目的返回錯誤型別是指raise還是errno都能跟著trycatch一起用
dev的時候能stackdump就stackdump，搞其他操作甚至忽略也可以。trycatch很靈活
然而真實情況下很多時候使用者不需要並且沒有權利去關心為什麼出錯，這種情況用狀態碼之類的就簡潔的多
8樓：
兩個都沒Result monad好用
type ('a, 'b) result =| Ok of 'a
| Error of 'b
9樓：
是這樣的
常規的報錯:~&%！！%?
而用了try catch
是這樣的
:親，你好，你的第*行，不通過哦，麻煩親檢查一下所以就這樣……
10樓：鐵原
樓上很多兄弟的回答都非常到位，我說一下我的觀點（不能再多同意 @張漢東 ）
我個人贊同使用try catch來處理業務
理由：現代業務系統是非常複雜的多層體系
經常發生0層發生故障 123等層無法處理，忽略，而N層可以處理，捕獲的情況
這是異常處理的跨層傳播
try catch提供了透明的跨層處理傳播機制（stack），中間層都不需要關注此異常。
但是錯誤碼就需要中間層對每乙個碼值進行列舉，包裝，重新return（也不能保證中間層都是有返回值的）
這對中間層原有的業務處理邏輯是一種侵入。
效能方面，trycatch略低，但現代vm下差異也不大了（還可以過載fullstack方法，將效能消耗降到最低） 。一般業務系統開發，清晰性應該放到第一位。
11樓：
搬運 Raymond Chen 的文章
12樓：李天宇
返回錯誤型別，我在這裡理解為C syscall一類的error code return。這麼來說的話，兩者最大區別在於exception可以跳過多個stack frame到最近的handler。取決於你的語言環境，這個過程可能會比較複雜，需要stack unwind。
所以在C++這樣的語言中有些時候exception是沒法保證被正確catch的（比如destructor裡）
那麼相對而言，返回錯誤碼就要保險得多，因為他並未跳出一般的calling convention。但是相對的，從軟體工程的角度來說，爽的是庫的提供者，蛋疼的是庫的呼叫者。舉例就是我寫乙個malloc永遠要查是不是返回null，不實際。
最後的結果就是使用者根本不查錯誤碼，造成更嚴重的損失。
加上現代語言的exception總體來說沒有什麼overhead cost，只要不進到catch block裡try catch基本沒有額外效能的代價。（別跟我槓編譯器的優化代價）所以基於API方面的好處，除非個別底層實現，都21世紀了用exception就好。
13樓：程墨Morgan
嚴格來說，是throw和返回錯誤型別的比對吧，try/catch相當於如何處理函式返回結果。
就記住乙個原則，throw出異常來，代表這種情況超出了這個函式的預料，所以，但凡是支援throw的語言，乙個函式覺得這情況我處理不了，就throw。
函式返回錯誤結果，雖然也能代表「這種情況我也不知怎麼搞」，但是這好歹說明你還預料到要出這種情況。
而且，返回錯誤結果，要求函式呼叫者處理，如果用throw，函式呼叫者不處理(try/catch)也行，就接著往呼叫棧上拋，總有人catch住，catch不住就crash了唄。
為啥haskell的getLine返回型別不直接是String
getLine是乙個函式，輸入乙個世界，輸出乙個字串和乙個被讀掉乙個字串的世界 然後你發現有很多類似的東西都有類似的格式 輸入乙個世界，輸出乙個東西和被操作後的世界你嫌棄這麼描述太麻煩，乾脆就用 IO 輸出的東西的型別表示輸入乙個世界，輸出乙個東西和被操作後的世界的型別 someone 因為純函式的...
如果乙個函式的錯誤返回值被包含在正確返回值之中，怎麼處理？
Menooker 用Optional scala裡可以用option，c 新標準裡有optional，都是用來裝乙個值，要麼有值，要麼就是None 直接不可以。因為，如，int i 對16位機，實際是int16 t i的允許取值範圍是 32768 32767，如果想同時再返回乙個狀態量，用於表示是否...
C 返回類時，返回引用還是構造乙個新的例項，什麼時候返回const？
Sunchy321 1 把print的形參改成A const 我不能理解為什麼要改成右值引用，如果有人能向我解釋清楚我非常感謝。A 能接受A const大概說明了什麼。2 我認為，是否返回引用其實取決於返回值是不是乙個新的物件。當然，operator 有其準則，也就是模仿內建運算子的行為 當然，不可...