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