Java异常处理中的一些特殊情况举例
只使用try和finally不使用catch的原因和场景
jdk并发工具包中,很多异常处理都使用了如下的结构,如abstractexecutorservice,即只有try和finally没有catch。
class x { private final reentrantlock lock = new reentrantlock(); // ... public void m() { lock.lock(); // block until condition holds try { // ... method body } finally { lock.unlock() } } }
为什么要使用这种结构?有什么好处呢?先看下面的代码
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可能出现而自己又无法处理的异常,但是在方法内部做自己应该的事情。
finally语句不会被执行的情况
java的finally语句不会被执行的唯一情况是:先执行了用于终止程序的system.exit()方法
public class test { public static void main(string[] args) { try { system.out.println("start"); system.exit(0); }finally { system.out.println("finally"); } system.out.println("end"); } }
输出结果为:
start
当然,如果在执行一般的没有system.exit()语句的try语句时,突然断电了,这时所有进程都会终止,也不会执行finally语句。
上一篇: mybatis 多条件查询、in查询