lity semantics.
Set<Throwable> dejaVu =
Collections.newSetFromMap(new IdentityHashMap<Throwable, Boolean>());
dejaVu.add(this);
synchronized (s.lock()) {
// Print our stack trace
s.println(this);
StackTraceElement[] trace = getOurStackTrace();
for (StackTraceElement traceElement : trace)
s.println("\tat " + traceElement);
// Print suppressed exceptions, if any
for (Throwable se : getSuppressed())
se.printEnclosedStackTrace(s, trace, SUPPRESSED_CAPTION, "\t", dejaVu);
// Print cause, if any
Throwable ourCause = getCause();
if (ourCause != null)
ourCause.printEnclosedStackTrace(s, trace, CAUSE_CAPTION, "", dejaVu);
}
}
...
暂不关心同步问题,可知,打印异常名和细节信息的代码为:
s.println(this);
JVM在运行期通过动态绑定实现this引用上的多态调用。继续追踪的话,最终会调用this实例的toString()方法。所有异常的最低公共祖先类是Throwable类,它提供了默认的toString()实现,大部分常见的异常类都没有覆写这个实现,我们自定义的异常也可以直接继承这个实现:
...
public String toString() {
String s = getClass().getName();
String message = getLocalizedMessage();
return (message != null) ? (s + ": " + message) : s;
}
...
public String getLocalizedMessage() {
return getMessage();
}
...
public String getMessage() {
return detailMessage;
}
...
显然,默认实现的打印格式就是示例的异常信息格式:异常名(全限定名)+细节信息。detailMessage由用户创建异常时设置,因此,如果有自定义的成员变量,我们通常在toString()方法中插入这个变量。参考com.sun.javaws.exceptions包中的BadFieldException,看看它如何插入自定义的成员变量field和value:
public String toString() {
return this.getValue().equals("https")?"BadFieldException[ " + this.getRealMessage() + "]":"BadFieldException[ " + this.getField() + "," + this.getValue() + "]";
}
严格的说,BadFieldException的toString中并没有直接插入field成员变量。不过这不影响我们理解,感兴趣的读者可自行翻阅源码。
总结
根据异常信息debug是程序员的基本技能,这里围绕异常信息的阅读和打印过程作了初步探索,后续还会整理一下常用的异常类,结合程序猿应该记住的几条基本规则,更好的理解如何用异常帮助我们写出clean code。
Java相当完备的异常处理机制是一把双刃剑,用好它能增强代码的可读性和鲁棒性,用不好则会让代码变的更加不可控。例如,在空指针上调用成员方法,运行期会抛出异常,这是很自然的——但是,是不可控的等待它在某个时刻某个位置抛出异常(实际上还是“确定”的,但对于debug来说是“不确定”的),还是可控的在进入方法伊始就检查并主动抛出异常呢?进一步的,哪些异常应该被即刻处理,哪些应该继续抛到外层呢?抛往外层时,何时需要封装异常呢?看看String#toLowerCase(),看看ProcessBuilder#start(),体会一下。