※ 引述《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