首页 > 学院 > 开发设计 > 正文

RuntimeException的特殊情况

2019-11-18 13:19:47
字体:
来源:转载
供稿:网友

  本章的第一个例子是:
  if(t == null)
  throw new NullPointerException();
  看起来似乎在传递进入一个方法的每个句柄中都必须检查null(因为不知道调用者是否已传递了一个有效的句柄),这无疑是相当可怕的。但幸运的是,我们根本不必这样做——它属于java进行的标准运行期检查的一部分。若对一个空句柄发出了调用,Java会自动产生一个NullPointerException违例。所以上述代码在任何情况下都是多余的。
  这个类别里含有一系列违例类型。它们全部由Java自动生成,毋需我们亲自动手把它们包含到自己的违例规范里。最方便的是,通过将它们置入单独一个名为RuntimeException的基础类下面,它们全部组合到一起。这是一个很好的继续例子:它建立了一系列具有某种共通性的类型,都具有某些共通的特征与行为。此外,我们没必要专门写一个违例规范,指出一个方法可能会“掷”出一个RuntimeException,因为已经假定可能出现那种情况。由于它们用于指出编程中的错误,所以几乎永远不必专门捕捉一个“运行期违例”——RuntimeException——它在默认情况下会自动得到处理。若必须检查RuntimeException,我们的代码就会变得相当繁复。在我们自己的包里,可选择“掷”出一部分RuntimeException。
  假如不捕捉这些违例,又会出现什么情况呢?由于编译器并不强制违例规范捕捉它们,所以假如不捕捉的话,一个RuntimeException可能过滤掉我们到达main()方法的所有途径。为体会此时发生的事情,请试试下面这个例子:
  
  //: NeverCaught.java
  // Ignoring RuntimeExceptions
  
  public class NeverCaught {
   static void f() {
    throw new RuntimeException("From f()");
   }
   static void g() {
    f();
   }
   public static void main(String[] args) {
    g();
   }
  } ///:~
  
  大家已经看到,一个RuntimeException(或者从它继续的任何东西)属于一种非凡情况,因为编译器不要求为这些类型指定违例规范。
  输出如下:
  
  java.lang.RuntimeException: From f()
  at NeverCaught.f(NeverCaught.java:9)
  at NeverCaught.g(NeverCaught.java:12)
  at NeverCaught.main(NeverCaught.java:15)
  
  所以答案就是:假若一个RuntimeException获得到达main()的所有途径,同时不被捕捉,那么当程序退出时,会为那个违例调用PRintStackTrace()。
  注重也许能在自己的代码中仅忽略RuntimeException,因为编译器已正确实行了其他所有控制。因为RuntimeException在此时代表一个编程错误:
  (1) 一个我们不能捕捉的错误(例如,由客户程序员接收传递给自己方法的一个空句柄)。
  (2) 作为一名程序员,一个应在自己的代码中检查的错误(如ArrayIndexOutOfBoundException,此时应注重数组的大小)。
  可以看出,最好的做法是在这种情况下违例,因为它们有助于程序的调试。
  另外一个有趣的地方是,我们不可将Java违例划分为单一用途的工具。的确,它们设计用于控制那些讨厌的运行期错误——由代码控制范围之外的其他力量产生。但是,它也非凡有助于调试某些非凡类型的编程错误,那些是编译器侦测不到的。

发表评论 共有条评论
用户名: 密码:
验证码: 匿名发表