你可以去读目前 javaworld文章 – “java tip 134: when catching exception, don’t cast your net too wide”。这篇文章警告了捕获java.lang.exception和java.lang.throable是不好的。捕获你能指定的异常对于代码的可维护性是十分重要的。然而这个规则依赖于特殊的环境。如果你不打算你的程序崩溃并且保留你的数据结构的安全异常,那么你必须捕获被抛出的真正的异常。
举个例子,想象你有一个加载了这个接口的服务器应用:
public interface ifoo
{
/**
* this method cant throw any checked exceptions…or can it?
*/
void bar ();
} // end of interface
对于给出参数的理由是让我们通知你这样的服务在什么地方,并且不同的ifoo实现能够从外部资源加载上。你写如下代码:
try
{
ifoo foo = … // get an ifoo implementation
foo.bar ();
}
catch (runtimeexception ioe)
{
// handle ioe …
}
catch (error e)
{
// handle or re-throw e …
}
并且你在这个里处理了所有可能的异常。你不需要在这里加上任何捕获java.io.ioexception的异常,因为ifoo实现没有从ifoo.bar()中抛出它,对吗?(事实上,如果你加上了捕获java.io.ioexception异常块,编译器可能会把它作为不可到达的异常而丢弃)
错误。在我写的evilfoo类中bar()方法证明了将抛出你传递给类构造器的任何异常:
public void bar ()
{
evilthrow.throwthrowable (m_throwthis);
}
运行main方法:
public class main
{
public static void main (final string[] args)
{
// this try/catch block appears to intercept all exceptions that
// ifoo.bar() can throw; however, this is not true
try
{
ifoo foo = new evilfoo (new java.io.ioexception ("surprise!"));
foo.bar ();
}
catch (runtimeexception ioe)
{
// ignore ioe
}
catch (error e)
{
// ignore e
}
}
} // end of class
你将看到从bar()方法抛出的java.io.ioexception异常实例并且没有任何捕获块:
>java -cp classes main
exception in thread "main" java.io.ioexception: surprise!
at main.main(main.java:23)
在这里发生了什么?
主要的观察是通常针对检测异常的java规则仅仅在编译的时候被执行。在运行的时候,一个jvm不能保证被一个方法抛出的异常是否和在这个方法中声明的抛出异常相匹配。因为调用方法的职责是捕获和处理所有从调用方法抛出的异常。任何没有被调用方法声明的异常将不予理睬并且拒绝调用栈。
如果正常行为是编译器执行,那么我怎么创建evilfoo的?至少有两个方法可以去创建抛出没有声明的异常的java方法:
thread.stop(throwable)在一些时候不被赞成使用,但是它仍然被使用并且传递一个throwable给被调用的thread。
分别编译:你能在编译evilfoo时候不去编译真正声明bar()方法抛出检测异常的ifoo临时版本。
我用后一种选择:我编译开始定义的evilthrow类:
public abstract class evilthrow
{
public static void throwthrowable (throwable throwable)
throws throwable
{
throw throwable;
}
}
接下来,我用byte code engineering library(bcel)的jasminvisitor分解结果,在汇编代码中删除throwthrowable()方法throwable的声明,并且用jasmin assembler 编译新的版本。
如果你编写捕获异常的构造器,那么它应该总是捕获java.lang.throwable而不仅仅只捕获java.lang.exception。这个规则适合你开发管理运行时的应用程序和必须执行可能包含错误甚至恶意代码的外部组件。你要确保捕获throwable并且过滤掉错误信息。
下面示例说明了如果你没有遵循这个建议将发生什么。
example: breaking swingutilities.invokeandwait()
javax.swing.swingutilities.invokeandwait()是在awt上执行一个线程的有用方法。当一个应用程序线程必须更新图形用户接口并且服从所有swing线程规则的时候这个方法将被调用。一个没有捕获runnable.run()抛出的异常将被捕获并且被封装在一个invocationtragetexception中重新抛出。
sun的j2se1.4.1假设这样一个未捕获的异常仅仅是java.lang.exception的子类。这里是一个swingutilities.invokeandwait()调用java.awt.event.invocationevent的一个分析:
public void dispatch() {
if (catchexceptions) {
try {
runnable.run();
}
catch (exception e) {
exception = e;
}
}
else {
runnable.run();
}
if (notifier != null) {
synchronized (notifier) {
notifier.notifyall();
}
}
}
这段代码的问题是如果runnable.run()抛出一个throwable,捕获块又没有并且notifier.notifyall()从来不会被执行。然后调用应用线程将等待在java.awt.eventqueue.invokeandwait()里的一个非公共锁对象(lock.wait()将从未执行):
public static void invokeandwait(runnable runnable)
throws interruptedexception, invocationtargetexception {
class awtinvocationlock {}
object lock = new awtinvocationlock();
invocationevent event =new invocationevent(toolkit.getdefaulttoolkit(), runnable, lock,
true);
synchronized (lock) {
toolkit.geteventqueue().postevent(event);
lock.wait();
}
exception eventexception = event.getexception();
if (eventexception != null) {
throw new invocationtargetexception(eventexception);
}
}
让evilfoo实现runnable接口:
public void run ()
{
bar ();
}
然后,在main中调用它:
swingutilities.invokeandwait (new evilfoo (new throwable ("surprise!")));
正如你看到的,未受信任代码使你的代码进入你没有准备处理的执行路径中的异常被保护起来。
