缺点：丢失的违例

2019-11-18 13:19:57

字体：大中小

来源：转载

供稿：网友

　　一般情况下，java的违例实施方案都显得十分出色。不幸的是，它依然存在一个缺点。尽管违例指出程序里存在一个危机，而且绝不应忽略，但一个违例仍有可能简单地“丢失”。在采用finally从句的一种非凡配置下，便有可能发生这种情况：
　　
　　//: LostMessage.java
　　// How an exception can be lost
　　
　　class VeryImportantException extends Exception {
　　　public String toString() {
　　　　return "A very important exception!";
　　　}
　　}
　　
　　class HoHumException extends Exception {
　　　public String toString() {
　　　　return "A trivial exception";
　　　}
　　}
　　
　　public class LostMessage {
　　　void f() throws VeryImportantException {
　　　　throw new VeryImportantException();
　　　}
　　　void dispose() throws HoHumException {
　　　　throw new HoHumException();
　　　}
　　　public static void main(String[] args)
　　　　　throws Exception {
　　　　LostMessage lm = new LostMessage();
　　　　try {
　　　　　lm.f();
　　　　} finally {
　　　　　lm.dispose();
　　　　}
　　　}
　　} ///:~
　　
　　输出如下：
　　
　　A trivial exception
　　　　　　at LostMessage.dispose(LostMessage.java:21)
　　　　　　at LostMessage.main(LostMessage.java:29)
　　
　　可以看到，这里不存在VeryImportantException（非常重要的违例）的迹象，它只是简单地被finally从句中的HoHumException代替了。
　　这是一项相当严重的缺陷，因为它意味着一个违例可能完全丢失。而且就象前例演示的那样，这种丢失显得非常“自然”，很难被人查出蛛丝马迹。而与此相反，C++里假如第二个违例在第一个违例得到控制前产生，就会被当作一个严重的编程错误处理。或许Java以后的版本会纠正这个问题（上述结果是用Java 1.1生成的）。

上一篇：RuntimeException的特殊情况

下一篇：用finally做什么

学习交流

索泰发布一款GTX 1070 Mini迷你版本:小机

索泰发布一款GTX 1070 Mini迷你版本:小机箱大爱...

热门图片

猜你喜欢的新闻

猜你喜欢的关注