我曾经看过一个程式 是否有错误是采用回传true or false来表示 boolean execute() 我问他怎麽这样做? 他表示这样比较有效率 我反问他 正常的情况下当然要有效率 可是难道发生错误也要很有效率吗 所以就改成 void execute() throws Exception 我看过几篇文章(我忘记是书还是文章了XD) 提供大家几个我常用的原则 1.如果不知道怎麽处理例外~那就抛出吧 2.尽可能的只处理例外"一次"或"一种" 3.不要用例外当成业务逻辑的判别方式 4.如果不知道~尽量使用RuntimeException来抛出 首先什麽是例外(楼上有人回文了) 我自己的定义是 如果发生某种状况使得整个作业或是方法必须停止,则为例外 例如 传送档案的时候,突然网路断掉了,那麽这个状况将造成整个传送的作业中止 那麽就需要抛出例外 那麽什麽有编译或执行 提供方法的API认为该例外有义务提醒使用该API的使用者 需要处理"有意义"的例外,那麽就要在编译的时候好提醒使用者要注意 (这里往往有个问题就是,虽然提供者很好心,但使用者往往也不知道该如何处理) 例如买便当的时候 必须要提醒使用者有下列的状况会发生喔 1.没有钱 2.买便当的人把钱A了 3.不够钱买便当 4.便当老板不卖便当了 5.买便当的人自己把便当吃掉了 以上这些就是自己认为有意义状况的例外 就会采用编译期的例外来提醒试使用者要注意(或处理) 但人算不如天算 总会有想不到的状况会发生 1.买便当的被车撞了 2.买便当的失恋了,所以不上班了 3.买便当的就是不爽帮你买便当啦 4.便当被狗抢走了 5...... 有好多 这麽多 非常有够多的状况会发生 天下红雨 娘要嫁人 晚上要看电视 结果却爆炸了 还是 这个要放在 荷花的左边 如果你想要预期上述的状况 那大概你的程式写到世界末日都还写不完 (世界末日也是例外喔) 但是这些都有一种特质就是 该状况都是会中止作业流程的,然後怎麽判别都判别不完 那就通通都拿去做RuntimeException拉 那麽在程式就不用事前去判别拉 (当然你要去判别也是可以) 例外并不是逻辑判别的一部份 那是因为要处理逻辑的时候 在某种状况发生的时候不可避免的会导致逻辑处理的中止 可是跟逻辑的关系也不是很强烈的情况下 但是还是要处理 那麽就为例外 ※ 引述《Shrugg (泪眼问花花不语)》之铭言： : 想请问一个一直都没办法在逻辑上说服自己的观念性问题 : 参考资料都说,程式的例外是用来撷取runtime时的例外情形,用来拦截例外的发生的. : 可是要是已经知道会有那些例外可能发生, : 设计程式时我们不是就会把限制条件给加上去了, : 根本不用等到例外发生了再来拦截吧? : Runtime会发生的例外都是设计程式时根本没想到的,既然没想到, : 为什麽会知道要怎麽去预防呢? : 像旗标的Java2第十四章以一个使用者输入错误当例子,程式例只能输入数字 : 但当使用者输入字串时就会是一个例外,所以程式安排这边设计一个拦截字串例外 : 发生时的处理. : 但是假设我是这个程式的开发者 : 我要是一开始就知道这个例外的存在,我就会设条件让使用者不能输入数字以外的资料了 : 如果我连这个例外都没有预估到,我又怎麽会知道要去拦截这个例外呢? : 希望有人知道我在说甚麽 -- --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 163.29.29.131 ※ 编辑: swpoker 来自: 163.29.28.131 (04/16 14:31)