※ 引述《Shrugg (淚眼問花花不語)》之銘言： : 謝謝版主的詳細回答, : 但是以這個例子來說,想吃便當是這個主管對這個程式的功能要求 : 既然已經都有考慮到所有可能的例外狀況了,為什麼不按照一開始的if去卡條件呢? : 版主後面用try & catch的方式好像也沒有比if的方法簡單方便. try跟catch還比if : 的字母還多. 我想你可能要更仔細地看一下 我那篇搞笑文當中，每段程式碼的差異 這樣或許有點老王賣瓜的嫌疑 但是基本上每段程式碼 & 說明、甚至註解的哏 基本上都是有意義、而不是單純要搞笑 （是說我也正經不起來...... [核爆]） 因為上一篇文章已經寫過了，我在這裡只重新強調結論 用 if-else / switch 這種傳統的條件控制結構，不是不行 但是寫起來會不夠方便、不夠好讀、甚至會很詭異 （難道你真的希望「便當」這個 class 要有「is沒錢買屁()」這個 method？ [核爆]） 順便補充一些之前忘記講的 用 try-catch 可以讓 caller 跟 callee 更加脫節 這在我上一篇文章的最後一個例子就說明了這個 「跑腿v3」基本上不會丟出「便當賣完意外」 但是主管卻可以先預防這個可能 或著再往回推一點（也許我跳太快） 用 try-catch，你不用太了解 callee 的細節 包括會回傳哪些值？ 拿到回傳值要檢查哪些 field 或 method（例如屁味）？ 原本不用回傳東西的 callee 也可以繼續保持 void 如果是 checked exception 你沒有 try-catch，compiler 還會翻臉不認帳 至於你說 try-catch 要寫的字比 if-else 多... 我只能說，你大概還沒開始用 IDE？ 然後，如果你的「買便當意外」血緣關係處理得好 像這樣（縮排表示是上一層的 child node） 買便當意外 跟錢有關的意外 沒錢買便當意外 錢不夠買便當意外 餐廳的意外 便當賣完意外 沒有這種便當意外 本日公休意外 餐廳倒店意外 假設「完美跑腿」都會很精確地丟出特定的 exception class 但是 caller 卻可以這樣 try { 完美跑腿.買便當(request, money); } catch (Exception e) { //管你是買便當意外還是世界末日 } 也可以這樣 try { 完美跑腿.買便當(request, money); } catch (跟錢有關的意外 moneyException) { //以後直接給跑腿百萬美金 } catch (餐廳的意外 shopException) { //算了，不吃不會死 } 或是 try { 完美跑腿.買便當(request, money); } catch (便當賣完意外 e1) { //.... } catch (沒有這種便當意外 e2) { //.... } catch (買便當意外 e) { //其他狀況都算在這裡 } 我想，如果你要用 if-else 也一定弄的出來 但是肯定會打的比 try-catch 多字 : 還是說例外可以一次攔截各種狀況? 所以比較好用? : 可是例外的try & catch還是要提供例外的狀況不是嗎? : 這樣又回到原來的命題了.即:我如果猜的到例外,還會讓例外發生嗎? : 然而綜合大家的回答,例外的狀況看起來似乎是Compile時就已經被預料到, : 而不是真的如字面的"例外"是無法預期的,所以是不是稱作"狀況"會比較不容易誤解? : 如果是"狀況"那現在問題變成了"我不了解使用例外比使用其他方法好在哪裡了" : 有人提到Soket斷線時無法用if. 但是可以用timeout不是嗎? : 有人提到if會寫不完. try & catch不是也會寫不完? : 謝謝大家這麼熱心的回答,我覺得Java板好熱情,難道是咖啡的問題:) 看來你是新來 Java 版... [慘笑] 不過，醜話先說在前頭 如果別人辛苦回覆你的東西你沒有好好研究 就重複重複再重複的問同樣的問題 那麼你就會覺得 Java 版（尤其是某 P版主）很愛酸人了 -- 錢鍾書： 說出來的話 http://www.psmonkey.org 比不上不說出來的話 Java 版 cookcomic 版 只影射著說不出來的話 and more...... --

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