問題(Question)：
除了使用STL或是第三方函式庫，我會特別注意需不需要catch例外以外，自己編寫
程式大多都還是用旗標或返回值的方式來處理錯誤，因為我對什麼情況下該使用例
外處理其實沒有什麼概念。
比方說書上在介紹例外處理的章節，大多都採用除0錯誤當成範例，但除0錯誤可
以藉由運算前檢查除數來避免，為什麼會特別為此定義一個例外呢？還有像是
fstream若開檔失敗，則是藉由檢查實例來偵測，為什麼不拋出std::system_error
來作為表示呢？因為沒辦法從中抓到一個明確的規律或依據，我不太懂得什麼樣
的場合或情境，使用例外處理而不是判斷旗標或返回值。
請問關於這部分是不是有什麼技巧或經驗可以請各位先進提點一下呢？
謝謝。

除以 0 會產生 interrupt 那跟 CPU 內的除法器設計有關也有一些浮點除法器會直接除出無限大或 NaN 給你就結案我自己寫 library 也不用例外機制而用傳回值表示因為我希望他在 C 和 C++ 都能通用

你說的「例外處理」，指的是 C++ 的 exception，還是指另外寫 code 處理？還有「例外」，是哪種類型的例外？

使用try、catch、throw語法的例外處理

對exception的態度其實人人不同，沒有統一規則相對比較中庸的說法是你想得到的錯誤就直接檢查，想不到的就留給例外去抓，但即便如此還是很模糊比如硬碟壞軌，這是一種可以預想到的錯誤，但你不可能為了想得到這個發生機率相對低的狀況，就在所有讀寫前面都加上壞軌檢測過了才讀寫另外就是有些語言根本已經把exception內化成一種流程控制手段而非單單的錯誤處理，所以某些地方用起來只是另一種if，而且「可能」寫起來比較簡單，這又是另一種狀況了

大哉問 我覺得是沒辦法回復的錯誤 用例外處理剩下可以回復 或是可以回傳錯誤傳值給使用者的用C的錯誤處理 這是我的習慣 也許別人不是這樣

我是比較不會用能否回復來做為區分，自己的基本概念是預防與治療，你事先寫好的判斷就是預防它發生或者發生了也不會造成問題，所以反而不會有恢復行為。比如事前判斷除以零會出錯，所以提早發現0，直接不除，所以預防了事情直接發生治療則是事情讓它發生了，事前沒有預料、或者就算預料到也無法不讓它發生，所以只好讓它發生後做一些治療方案，看要盡可能繼續跑或至少留些log再死所以我的區分標準比較像是「你能否阻止它發生」但是因為某些便利性或者語言特性（如Python），我其實也沒這麼遵守這概念就是，還是很彈性去處理這問題XD

某些語言第一個想到的就是那個J開頭的XD

Python也是啊，連基本的for loop行為就是一直callnext()直到iterator丟出StopIteration exception而中斷Python也有不少基本跟常用package根本上就完全使用例外來回應所有正常完成以外的狀態，完全讓你被迫使用我抱持上面講到的概念剛從C/C++轉而接觸到Python想說「靠，怎麼滿地都是exception強迫使用啊？」結果現在也是用爽爽了XD

我也有類似的疑惑，CppCon有類似的主題在說我自己理解是對於pre/postcondition用類assert的機制針對邏輯上的失敗，可以用expected這種方式可能會發生但也不知道怎麼處理(OOM)的就用exceptionHerb有提議新的exception機制，感覺Rust做法和他很像裡面提到因例外發生時效率差太多，所以社群主流都不使用前面說的針對邏輯上的失敗描述不太好，應該說像是開檔或是把字串變成數字這種任務，通常不會希望因非法字串就丟個例外讓人處理，因為業務邏輯上本身很有可能發生

可以使用 try catch 的語法來進行錯誤例外處理，會比使用 if 還方便許多，而且有些狀況是完全沒辦法使用判斷式來進行錯誤處理的。 但像您的狀況，也可以在執行除法之前先檢查除數。

我是寫utility很習慣會throw，卻不知道catch後怎麼處理好已檢查出某些狀況會導致後續動作無法正常執行 就可以throw

一般是會用前者 不過理由跟你想探討的錯誤處理無關XD

我是寫android 程式才有感覺。可是這裡是C板XD底層太抽象+錯誤資訊跟回傳值想分離的時候好用