|
输出结果是： java.lang.Exception at ExceptionDemo.schoolmaster(ExceptionDemo.java:9) at ExceptionDemo.teacher(ExceptionDemo.java:6) at ExceptionDemo.student(ExceptionDemo.java:3) at ExceptionDemo.main(ExceptionDemo.java:13) 可以看出函数的调用栈，一级一级地哭诉…… 10、谁之错？一般地，异常不是我们程序员的错，不是程序设计上的缺陷。比如读取一个重要文件，这个文件被用户误删了；正上着网呢，网线被用户的宠物咬断了。为了程序的健壮性，我们尽量考虑出现可能性大的异常，并处理，但我们不能穷尽。 11、异常的捕获之一。catch子句的参数是某种类型异常的对象，如果抛出的异常是该参数的子类，那么这个异常将被它捕获。也就是说被抛出的异常不会精确地寻找最匹配的捕获者（catch子句），只要是它的继承结构的直系上层就可以捕获它。 按照这个逻辑，catch(Exception e) 不就能捕获所有的异常吗？事实上，确实如此。 但是一般地，不建议使用这种一站式的异常处理。因为这样就丢失了具体的异常信息，不能为某个具体的异常编写相应的异常处理代码，失去了异常处理的意义。从哲学角度来讲，具体问题要具体分析，能治百病的万能药一般都是无效的保健品。 Java在此处为什么这么设计呢？因为有另一种机制的存在，请看下条分解。 12、异常的捕获之二。 当抛出一个异常时，Java试图寻找一个能捕获它的catch子句，如果没找到就会沿着栈向下传播。这个过程就是异常匹配。Java规定：最具体的异常处理程序必须总是放在更普通异常处理程序的前面。这条规定再合理不过了，试想如果把catch(Exception e)放在最上面，那么下面的catch子句岂不是永远不能执行了？如果你非要把更普遍的异常处理放在前面，对不起，通不过编译！虽然编译器不会这样报错：“It is so stupid to do like that!”…… 13、捕获或声明规则。 如果在一个方法中抛出异常，你有两个选择：要么用catch子句捕获所有的异常，要么在方法中声明将要抛出的异常,否则编译器不会让你得逞的。 方案一：处理异常 void ex() { try { throw new Exception(); } catch (Exception e) { e.printStackTrace(); } } 方案二：抛出去 void ex() throws Exception { throw new Exception(); } 比较一下行数就知道了，在代码的世界里推卸责任也是那么简单，一个throws关键字包含了多少人生哲理啊……现实生活中我们有很多角色，儿女、父母、学生、老师、老板、员工……每个人都占了几条。可是你能尽到所有责任吗？按照古代的孝道，父母尚在人世就不能远行。各种责任是有矛盾的，顾此失彼啊。 但是这条规则有个特例。一个继承自Exception名为RuntimeException的子类，也就是运行时异常，不受上述规则的限制。下面的代码完全能编译，只不过调用之后在运行时会抛出异常。 void ex() { throw new RuntimeException(); } 14、throw和thrwos关键字。throw用在方法体中抛出异常，后面是一个具体的异常对象。throws用在方法参数列表括号的后面，用来声明此方法会抛出的异常种类，后面跟着一个异常类。 15、非检查异常。RuntimeException、Error以及它们的子类都是非检查异常，不要求定义或处理非检查异常。Java2类库中有很多方法抛出检查异常，因此会常常编写异常处理程序来处理不是你编写的方法产生的异常。这种机制强制开发人员处理错误，使得Java程序更加健壮，安全。 16、自定义异常类型。觉得现有的异常无法描述你想抛出的异常，ok！Java允许你自定义异常类型，只需要继承Exception或者它的子类，然后换上有个性的名字。 class NotEnoughMoney extends Exception { public NotEnoughMoney() { } public NotEnoughMoney(String msg) { super(msg); } } 希望大家在生活里不要抛出类似的异常。
|
