※ 引述《Shrugg (淚眼問花花不語)》之銘言： : 想請問一個一直都沒辦法在邏輯上說服自己的觀念性問題 : 參考資料都說,程式的例外是用來擷取runtime時的例外情形,用來攔截例外的發生的. : 可是要是已經知道會有那些例外可能發生, : 設計程式時我們不是就會把限制條件給加上去了, : 根本不用等到例外發生了再來攔截吧? 前提:已經知道 那為了怕還有沒想到的東西要怎麼做呢? 這樣嗎? else{ ooxx; } 那跟例外其實是一樣的概念 只是有一個很大的問題 你沒有辦法從一個if else的scope跳到另一個去 第二個 這樣寫會產生很恐怖的巢狀結構 因為每個if else裡面都會有更多的程式碼要執行 原本是n層的邏輯判斷 若因為裡面呼叫的function可能回傳false來表示錯誤 那又要多一層來包他變成n+1 包了就算了 上層還是不知道到底是在錯啥鬼 於是又要去get一些結果來判斷 然後判斷完還要處理 而且這還是"呼叫一個function就要做一次的事情" 全部寫完 整坨東西的可讀性....? 的確 拋出exception的效能比較差 但是效能可以用機器來彌補 且exception不應該太常出現 所以不要把業務邏輯放在exception裡面其實也跟效能議題有關 但是基於程式碼的可維護性以及再利用性 try-catch是相當方便的開發方式 : Runtime會發生的例外都是設計程式時根本沒想到的,既然沒想到, : 為什麼會知道要怎麼去預防呢? : 像旗標的Java2第十四章以一個使用者輸入錯誤當例子,程式例只能輸入數字 : 但當使用者輸入字串時就會是一個例外,所以程式安排這邊設計一個攔截字串例外 : 發生時的處理. : 但是假設我是這個程式的開發者 : 我要是一開始就知道這個例外的存在,我就會設條件讓使用者不能輸入數字以外的資料了 : 如果我連這個例外都沒有預估到,我又怎麼會知道要去攔截這個例外呢? : 希望有人知道我在說甚麼 這種範例當然可以預防 因為作者只是舉例... 實際上 多數有經驗的程式在許多參數截取時都會預先針對null做判斷 看是要回傳特定訊息還是什麼的 但是這是因為邏輯上相對簡單卻又常發生 用個if else處理掉相對容易 也不會讓程式邏輯架構整個暴走 可是在處理複雜的邏輯時 根本不可能所有事情都考慮到 甚至有的api就是跟你講他會丟exception出來 這時候用個try catch就會輕鬆很多了 --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 114.32.105.1