java try没有catch

JDK并发工具包中，很多异常处理都使用了如下的结构，如AbstractExecutorService，即只有try和finally没有catch。

[java] view plain copy

print?

1. class X   
2. {  
3.     private final ReentrantLock lock = new ReentrantLock();  
4.     // …  
5.    
6.     public void m()  
7.     {  
8.     lock.lock();  // block until condition holds  
9.     try   
10.     {  
11.         // … method body  
12.     } finally  
13.     {  
14.         lock.unlock()  
15.     }  
16.      }  
17. }  

class X {    private final ReentrantLock lock = new ReentrantLock();    // ...    public void m()    {    lock.lock();  // block until condition holds    try     {        // ... method body    } finally    {        lock.unlock()    }     }}

为什么要使用这种结构？有什么好处呢？先看下面的代码

[java] view plain copy

print?

1. public void testTryAndFinally(String name)  
2. {  
3.        try  
4.        {  
5.            name.length();// NullPointerException  
6.        }  
7.        finally  
8.        {  
9.            System.out.println(”aa”);  
10.        }  
11. }  

 public void testTryAndFinally(String name) {        try        {            name.length();// NullPointerException        }        finally        {            System.out.println("aa");        } }

传递null调用该方法的执行结果是：在控制台打印aa，并抛出NullPointerException。即程序的执行流程是先执行try块，出现异常后执行finally块，最后向调用者抛出try中的异常。这种执行结果是很正常的，因为没有catch异常处理器，所有该方法只能将产生的异常向外抛；因为有finally，所以会在方法返回抛出异常之前，先执行finally代码块中的清理工作。

 

这种做法的好处是什么呢？对于testTryAndFinally来说，它做了自己必须要做的事(finally)，并向外抛出自己无法处理的异常；对于调用者来说，能够感知出现的异常，并可以按照需要进行处理。也就是说这种结构实现了职责的分离，实现了异常处理(throw)与异常清理(finally)的解耦，让不同的方法专注于自己应该做的事。

那什么时候使用try-finally，什么时候使用try-catch-finally呢？很显然这取决于方法本身是否能够处理try中出现的异常。如果自己可以处理，那么直接catch住，不用抛给方法的调用者；如果自己不知道怎么处理，就应该将异常向外抛，能够让调用者知道发生了异常。即在方法的签名中声明throws可能出现而自己又无法处理的异常，但是在方法内部做自己应该的事情。这可以参考ExecutorService.invokeAny()的方法签名

[java] view plain copy

print?

1. <T> T invokeAny(Collection<? extends Callable<T>> tasks) throws InterruptedException, ExecutionException;  

 <T> T invokeAny(Collection<? extends Callable<T>> tasks) throws InterruptedException, ExecutionException;