你的位置:首页 > Java教程

[Java教程]编写高质量代码:改善Java程序的151个建议(第8章:异常___建议114~117)


建议114:不要在构造函数中抛出异常

  Java异常的机制有三种:

  • Error类及其子类表示的是错误,它是不需要程序员处理也不能处理的异常,比如VirtualMachineError虚拟机错误,ThreadDeath线程僵死等。
  • RunTimeException类及其子类表示的是非受检异常,是系统可能会抛出的异常,程序员可以去处理,也可以不处理,最经典的就是NullPointException空指针异常和IndexOutOfBoundsException越界异常。
  • Exception类及其子类(不包含非受检异常),表示的是受检异常,这是程序员必须处理的异常,不处理则程序不能通过编译,比如IOException表示的是I/O异常,SQLException表示的数据库访问异常。  

我们知道,一个对象的创建过程经过内存分配,静态代码初始化、构造函数执行等过程,对象生成的关键步骤是构造函数,那是不是也允许在构造函数中抛出异常呢?从Java语法上来说,完全可以在构造函数中抛出异常,三类异常都可以,但是从系统设计和开发的角度来分析,则尽量不要在构造函数中抛出异常,我们以三种不同类型的异常来说明之。

(1)、构造函数中抛出错误是程序员无法处理的

  在构造函数执行时,若发生了VirtualMachineError虚拟机错误,那就没招了,只能抛出,程序员不能预知此类错误的发生,也就不能捕捉处理。

(2)、构造函数不应该抛出非受检异常

  我们来看这样一个例子,代码如下:

class Person {  public Person(int _age) {    // 不满18岁的用户对象不能建立    if (_age < 18) {      throw new RuntimeException("年龄必须大于18岁.");    }  }  public void doSomething() {    System.out.println("doSomething......");  }}

  这段代码的意图很明显,年龄不满18岁的用户不会生成一个Person实例对象,没有对象,类行为doSomething方法就不可执行,想法很好,但这会导致不可预测的结果,比如我们这样引用Person类: 

public static void main(String[] args) {    Person p = new Person(17);    p.doSomething();    /*其它的业务逻辑*/  }

  很显然,p对象不能建立,因为是一个RunTimeException异常,开发人员可以捕捉也可以不捕捉,代码看上去逻辑很正确,没有任何瑕疵,但是事实上,这段程序会抛出异常,无法执行。这段代码给了我们两个警示:

  1. 加重了上层代码编写者的负担:捕捉这个RuntimeException异常吧,那谁来告诉我有这个异常呢?只有通过文档约束了,一旦Person类的构造函数经过重构后再抛出其它非受检异常,那main方法不用修改也是可以测试通过的,但是这里就可能会产生隐藏的缺陷,而写还是很难重现的缺陷。不捕捉这个RuntimeException异常,这个是我们通常的想法,既然已经写成了非受检异常,main方法的编码者完全可以不处理这个异常嘛,大不了不执行Person的方法!这是非常危险的,一旦产生异常,整个线程都不再继续执行,或者链接没有关闭,或者数据没有写入数据库,或者产生内存异常,这些都是会对整个系统产生影响。
  2. 后续代码不会执行:main方法的实现者原本是想把p对象的建立作为其代码逻辑的一部分,执行完doSomething方法后还需要完成其它逻辑,但是因为没有对非受检异常进行捕捉,异常最终会抛出到JVM中,这会导致整个线程执行结束后,后面所有的代码都不会继续执行了,这就对业务逻辑产生了致命的影响。

(3)、构造函数尽可能不要抛出受检异常

  我们来看下面的例子,代码如下:

//父类class Base {  // 父类抛出IOException  public Base() throws IOException {    throw new IOException();  }}//子类class Sub extends Base {  // 子类抛出Exception异常  public Sub() throws Exception {  }}

  就这么一段简单的代码,展示了在构造函数中抛出受检异常的三个不利方面:

  1. 导致子类膨胀:在我们的例子中子类的无参构造函数不能省略,原因是父类的无参构造函数抛出了IOException异常,子类的无参构造函数默认调用的是父类的构造函数,所以子类无参构造函数也必须抛出IOException或其父类。
  2. 违背了里氏替换原则:"里氏替换原则" 是说父类能出现的地方子类就可以出现,而且将父类替换为子类也不会产生任何异常。那我们回头看看Sub类是否可以替换Base类,比如我们的上层代码是这样写的:
public static void main(String[] args) {    try {      Base base = new Base();    } catch (Exception e) {        e.printStackTrace();    }  }

  然后,我们期望把new Base()替换成new Sub(),而且代码能够正常编译和运行。非常可惜,编译不通过,原因是Sub的构造函数抛出了Exception异常,它比父类的构造函数抛出更多的异常范围要宽,必须增加新的catch块才能解决。  

  可能大家要问了,为什么Java的构造函数允许子类的构造函数抛出更广泛的异常类呢?这正好与类方法的异常机制相反,类方法的异常是这样要求的:

// 父类class Base {  // 父类方法抛出Exception  public void testMethod() throws Exception {  }}// 子类class Sub extends Base {  // 父类方法抛出Exception  @Override  public void testMethod() throws IOException {  }}

  子类的方法可以抛出多个异常,但都必须是覆写方法的子类型,对我们的例子来说,Sub类的testMethod方法抛出的异常必须是Exception的子类或Exception类,这是Java覆写的要求。构造函数之所以于此相反,是因为构造函数没有覆写的概念,只是构造函数间的引用调用而已,所以在构造函数中抛出受检异常会违背里氏替换原则原则,使我们的程序缺乏灵活性。

  3.子类构造函数扩展受限:子类存在的原因就是期望实现扩展父类的逻辑,但父类构造函数抛出异常却会让子类构造函数的灵活性大大降低,例如我们期望这样的构造函数。

// 父类class Base {  public Base() throws IOException{      }}// 子类class Sub extends Base {  public Sub() throws Exception{    try{      super();    }catch(IOException e){      //异常处理后再抛出      throw e;    }finally{      //收尾处理    }  }}

  很不幸,这段代码编译不通过,原因是构造函数Sub没有把super()放在第一句话中,想把父类的异常重新包装再抛出是不可行的(当然,这里有很多种 “曲线” 的实现手段,比如重新定义一个方法,然后父子类的构造函数都调用该方法,那么子类构造函数就可以自由处理异常了),这是Java语法机制。

  将以上三种异常类型汇总起来,对于构造函数,错误只能抛出,这是程序人员无能为力的事情;非受检异常不要抛出,抛出了 " 对己对人 " 都是有害的;受检异常尽量不抛出,能用曲线的方式实现就用曲线方式实现,总之一句话:在构造函数中尽可能不出现异常。

  注意 :在构造函数中不要抛出异常,尽量曲线实现。

建议115:使用Throwable获得栈信息

  AOP编程可以很轻松的控制一个方法调用哪些类,也能够控制哪些方法允许被调用,一般来说切面编程(比如AspectJ),只能控制到方法级别,不能实现代码级别的植入(Weave),比如一个方法被类A的m1方法调用时返回1,在类B的m2方法调用时返回0(同参数情况下),这就要求被调用者具有识别调用者的能力。在这种情况下,可以使用Throwable获得栈信息,然后鉴别调用者并分别输出,代码如下: 

class Foo {  public static boolean method() {    // 取得当前栈信息    StackTraceElement[] sts = new Throwable().getStackTrace();    // 检查是否是methodA方法调用    for (StackTraceElement st : sts) {      if (st.getMethodName().equals("methodA")) {        return true;      }    }    return false;  }}//调用者class Invoker{  //该方法打印出true  public static void methodA(){    System.out.println(Foo.method());  }  //该方法打印出false  public static void methodB(){    System.out.println(Foo.method());  }}

  注意看Invoker类,两个方法methodA和methodB都调用了Foo的method方法,都是无参调用,返回值却不同,这是我们的Throwable类发挥效能了。JVM在创建一本Throwable类及其子类时会把当前线程的栈信息记录下来,以便在输出异常时准确定位异常原因,我们来看Throwable源代码。

public class Throwable implements Serializable {  private static final StackTraceElement[] UNASSIGNED_STACK = new StackTraceElement[0];  //出现异常记录的栈帧  private StackTraceElement[] stackTrace = UNASSIGNED_STACK;  //默认构造函数  public Throwable() {
//记录栈帧 fillInStackTrace(); } //本地方法,抓取执行时的栈信息 private native Throwable fillInStackTrace(int dummy); public synchronized Throwable fillInStackTrace() { if (stackTrace != null || backtrace != null /* Out of protocol state */) { fillInStackTrace(0); stackTrace = UNASSIGNED_STACK; } return this; }}

  在出现异常时(或主动声明一个Throwable对象时),JVM会通过fillInStackTrace方法记录下栈帧信息,然后生成一个Throwable对象,这样我们就可以知道类间的调用顺序,方法名称及当前行号等了。

  获得栈信息可以对调用者进行判断,然后决定不同的输出,比如我们的methodA和methodB方法,同样地输入参数,同样的调用方法,但是输出却不同,这看起来很想是一个bug:方法methodA调用method方法正常显示,而方法methodB调用却会返回错误数据,因此我们虽然可以根据调用者的不同产生不同的逻辑,但这仅局限在对此方法的广泛认知上,更多的时候我们使用method方法的变形体,代码如下:  

class Foo {  public static boolean method() {    // 取得当前栈信息    StackTraceElement[] sts = new Throwable().getStackTrace();    // 检查是否是methodA方法调用    for (StackTraceElement st : sts) {      if (st.getMethodName().equals("methodA")) {        return true;      }    }    throw new RuntimeException("除了methodA方法外,该方法不允许其它方法调用");  }}

  只是把“return false” 替换成了一个运行期异常,除了methodA方法外,其它方法调用都会产生异常,该方法常用作离线注册码校验,让破解者视图暴力破解时,由于执行者不是期望的值,因此会返回一个经过包装和混淆的异常信息,大大增加了破解难度。

建议116:异常只为异常服务

  异常只为异常服务,这是何解?难道异常还能为其它服务不成?确实能,异常原本是正常逻辑的一个补充,但是有时候会被当做主逻辑使用,看如下代码:

//判断一个枚举是否包含String枚举项  public static <T extends Enum<T>> boolean Contain(Class<T> clz,String name){    boolean result = false;    try{      Enum.valueOf(clz, name);      result = true;    }catch(RuntimeException e){      //只要是抛出异常,则认为不包含    }    return result;  }

  判断一个枚举是否包含指定的枚举项,这里会根据valueOf方法是否抛出异常来进行判断,如果抛出异常(一般是IllegalArgumentException异常),则认为是不包含,若不抛出异常则可以认为包含该枚举项,看上去这段代码很正常,但是其中有是哪个错误:

  1. 异常判断降低了系统的性能
  2. 降低了代码的可读性,只有详细了解valueOf方法的人才能读懂这样的代码,因为valueOf抛出的是一个非受检异常
  3. 隐藏了运行期可能产生的错误,catch到异常,但没有做任何处理。

  我们这段代码是用一段异常实现了一个正常的业务逻辑,这导致代码产生了坏味道。要解决从问题也很容易,即不在主逻辑中实使用异常,代码如下:  

  // 判断一个枚举是否包含String枚举项  public static <T extends Enum<T>> boolean Contain(Class<T> clz, String name) {    // 遍历枚举项    for (T t : clz.getEnumConstants()) {      // 枚举项名称是否相等      if (t.name().equals(name)) {        return true;      }    }    return false;  }

  异常只能用在非正常的情况下,不能成为正常情况下的主逻辑,也就是说,异常是是主逻辑的辅助场景,不能喧宾夺主。

  而且,异常虽然是描述例外事件的,但能避免则避免之,除非是确实无法避免的异常,例如: 

public static void main(String[] args) {    File file = new File("a.txt");    try {      FileInputStream fis = new FileInputStream(file);      // 其它业务处理    } catch (FileNotFoundException e) {      e.printStackTrace();      // 异常处理    }  }

  这样一段代码经常在我们的项目中出现,但经常写并不代表不可优化,这里的异常类FileNotFoundException完全可以在它诞生前就消除掉:先判断文件是否存在,然后再生成FileInputStream对象,这也是项目中常见的代码:

  public static void main(String[] args) {    File file = new File("a.txt");    // 经常出现的异常,可以先做判断    if (file.exists() && !file.isDirectory()) {      try {        FileInputStream fis = new FileInputStream(file);        // 其它业务处理      } catch (FileNotFoundException e) {        e.printStackTrace();        // 异常处理      }    }  }

  虽然增加了if判断语句,增加了代码量,但是却减少了FileNotFoundException异常出现的几率,提高了程序的性能和稳定性。

建议117:多使用异常,把性能问题放一边

  我们知道异常是主逻辑的例外逻辑,举个简单的例子来说,比如我在马路上走(这是主逻辑),突然开过一辆车,我要避让(这是受检异常,必须处理),继续走着,突然一架飞机从我头顶飞过(非受检异常),我们可以选在继续行走(不捕捉),也可以选择指责其噪音污染(捕捉,主逻辑的补充处理),再继续走着,突然一颗流星砸下来,这没有选择,属于错误,不能做任何处理。这样具备完整例外场景的逻辑就具备了OO的味道,任何一个事务的处理都可能产生非预期的效果,问题是需要以何种手段来处理,如果不使用异常就需要依靠返回值的不同来进行处理了,这严重失去了面向对象的风格。

  我们在编写用例文档(User case Specification)时,其中有一项叫做 " 例外事件 ",是用来描述主场景外的例外场景的,例如用户登录的用例,就会在" 例外事件 "中说明" 连续3此登录失败即锁定用户账号 ",这就是登录事件的一个异常处理,具体到我们的程序中就是:  

public void login(){    try{      //正常登陆    }catch(InvalidLoginException lie){      //  用户名无效    }catch(InvalidPasswordException pe){      //密码错误的异常    }catch(TooMuchLoginException){      //多次登陆失败的异常    }  }

  如此设计则可以让我们的login方法更符合实际的处理逻辑,同时使主逻辑(正常登录,try代码块)更加清晰。当然了,使用异常还有很多优点,可以让正常代码和异常代码分离、能快速查找问题(栈信息快照)等,但是异常有一个缺点:性能比较慢。

  Java的异常机制确实比较慢,这个"比较慢"是相对于诸如String、Integer等对象来说的,单单从对象的创建上来说,new一个IOException会比String慢5倍,这从异常的处理机制上也可以解释:因为它要执行fillInStackTrace方法,要记录当前栈的快照,而String类则是直接申请一个内存创建对象,异常类慢一筹也就在所难免了。

  而且,异常类是不能缓存的,期望先建立大量的异常对象以提高异常性能也是不现实的。

  难道异常的性能问题就没有任何可以提高的办法了?确实没有,但是我们不能因为性能问题而放弃使用异常,而且经过测试,在JDK1.6下,一个异常对象的创建时间只需1.4毫秒左右(注意是毫秒,通常一个交易是在100毫秒左右),难道我们的系统连如此微小的性能消耗都不予许吗?

  注意:性能问题不是拒绝异常的借口。




英国旅游价格特价英国游深圳到英国旅游报价到英国旅游要多少钱英国旅游路线岭南印象园有什么花看?广州岭南印象园油菜花开了吗? 徽州三月好时光 青瓦白墙黄花香 东部华侨城什么时候去最好?深圳东部华侨城门票包括什么项目? 3月东部华侨城有什么好玩的?2015深圳东部华侨城最新门票价格? 道滘粤晖园门票价格?粤晖园拓展基地门票多少钱? 赏银杏最美好时节 原来徐州美景近在眼前 道滘粤晖园怎么走?粤晖园拓展基地自驾攻略? 东莞粤晖园地址?粤晖园拓展基地在哪里? 11月份适合去哪里旅游 适合旅游的海岛推荐 在马尔代夫一定要玩的项目 宁海温泉自驾游指南 花都香草世界有导游证免费吗?广州花都香草世界门票优惠政策?_香草世界旅游攻略_香草世界旅游景点 最强洗肺地哪里找 首选浪漫之都大连_大连旅游攻略_大连旅游景点 花都香草世界门票团购多少钱?广州花都香草世界团体票怎么买?_香草世界旅游攻略_香草世界旅游景点 花都香草世界网上订票?广州花都香草世界优惠票多少钱?_香草世界旅游攻略_香草世界旅游景点 MID-73H1C Datasheet MID-73H1C Datasheet MID-8541C Datasheet MID-8541C Datasheet MID-85A1C Datasheet MID-85A1C Datasheet 到俄罗斯旅游多少钱 到俄罗斯旅游多少钱 到俄罗斯旅游多少钱 云南旅游天气 云南旅游天气 云南旅游天气 葡萄牙美食 葡萄牙美食 葡萄牙美食