java只使用try和finally不使用catch的原因和场景
2016-04-27 10:58
676 查看
JDK并发工具包中,很多异常处理都使用了如下的结构,如AbstractExecutorService,即只有try和finally没有catch。
[java] view
plain copy
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
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
<T> T invokeAny(Collection<? extends Callable<T>> tasks) throws InterruptedException, ExecutionExce
[java] view
plain copy
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
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
<T> T invokeAny(Collection<? extends Callable<T>> tasks) throws InterruptedException, ExecutionExce
相关文章推荐
- Eclipse 4.5+(Mars)安装SVN
- Spring事务和异常回滚
- Java NumberFormatException详解
- Java基础知识IO流(字节流File读取操作)
- java四种运算符
- 深入理解java嵌套类和内部类、匿名类
- Java性能监控系列——java.lang.instrument
- Struts流程
- 今天晚上 中国互联网被Struts2漏洞血洗
- PAT乙级(Basic Level)真题 >福尔摩斯的约会 (Java记录)
- Struts2理解--动态方法和method属性及通配符_默认Action
- sha1加密java代码
- Java Observable 模式
- java代码实现二叉排序树
- 使用Rxjava缓存请求
- eclipse-4.4.2安装Groovy插件(其他版本eclipse可参考)
- JAVA 判断一个整数是否为2的整数次幂的方法
- spring注解
- eclipse上android NDK开发环境的搭建(android-ndk-r10d\docs\Getting Started with the NDK)
- java中关于protected的一些误解