try-with-statement语法糖总结

最近处理的sonar问题,近一半都是资源未关闭的问题,sonar提示我们可以使用try-with-statement来解决这类问题,我尝试和总结了如下:

这个是用来替代繁琐的try catch finnally

它会自动close 所有实现了java.lang.AutoCloseable接口的资源

写法是在try后面跟着一个小括号,把资源的声明代码写进去就ok了

try (BufferedReader br =

              new BufferedReader(new FileReader(path))) {

        return br.readLine();

}catch(IOExcepton e){

}

这个里面br就会在使用完毕后自动关闭,比如抛出异常,或是try代码块执行完毕的时候,会自动执行close,妈妈再也不用担心我们的close

这个小括号里面可以声明一个或是多个资源变量

这个写法等价于

BufferedReader br = new BufferedReader(new FileReader(path));

    try {

        return br.readLine();

    } catch(){

    }

    finally {

        // do br.close()  先简单这样理解,编译器对close抛出的异常做了move-exception操作这点无法用代码表述出来,详见后文    }

需要注意一点,它对Exception的抛出做了更友好的改进,通常在

//伪代码

try{

a = ClosableSteam()

} catch(Exception e){

}finnaly{

close()

}

里面如果catch了异常后在执行close的时候又抛出了异常,系统会抛出close时候的异常,这不利于定位问题,所以在使用try-with-statement里面引入了SupressedException的概念,相当于原代码段被处理成了如下方式

TryStudy tryStudy = null;

try{

tryStudy = new TryStudy();

System.out.println(tryStudy);

}catch(Throwable suppressedException) {

if (tryStudy != null) {

try {

tryStudy.close();

}catch(Throwable e) {

e.addSuppressed(suppressedException);

throw e;

}

}

throw suppressedException;

}

这样抛出的异常其实就是原异常,有助于我们定位真实的Exception点,这个原异常会在

try(){ //try-with-statement

}catch(Exception e){

}

这里的e里面拿到,如果一定要拿close时候抛的异常,那么在Exception中getSupressedException就可以了

抛出来的异常大概会长这样

java.io.IOException: doSomething IOException

at sg.bigo.lijiangyan.testtrywithstatement.MyClosableClass.doSomething(MyClosableClass.java:11)

at sg.bigo.lijiangyan.testtrywithstatement.MainActivity.onCreate(MainActivity.java:19)

at android.app.Activity.performCreate(Activity.java:7149)

at android.app.Activity.performCreate(Activity.java:7140)

at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1288)

at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:3017)

at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:3172)

at android.app.servertransaction.LaunchActivityItem.execute(LaunchActivityItem.java:78)

at android.app.servertransaction.TransactionExecutor.executeCallbacks(TransactionExecutor.java:108)

at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:68)

at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1906)

at android.os.Handler.dispatchMessage(Handler.java:106)

at android.os.Looper.loop(Looper.java:193)

at android.app.ActivityThread.main(ActivityThread.java:6863)

at java.lang.reflect.Method.invoke(Native Method)

at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:537)

at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:858)

Suppressed: java.io.IOException: close IOException

at sg.bigo.lijiangyan.testtrywithstatement.MyClosableClass.close(MyClosableClass.java:16)

at sg.bigo.lijiangyan.testtrywithstatement.MainActivity.onCreate(MainActivity.java:20)

... 15 more

可以看到这里跟了一个Suppressed部分

当然这里也要注意有坑,由于这个语法糖是在java7引入的,如果androidminsdk低于19,就不能用,但是android在支持java8后使用desugar解决了这个问题,所以我们的项目中可以愉快的使用

当然,还有更坑,要注意这是编译器帮我们加的,假如包装类在close中还做了其余可能抛出异常的代码,而这些代码在close之前,依旧可能发生泄露,例如,GZIPOutputStream https://juejin.im/entry/57f73e81bf22ec00647dacd0

try (FileInputStream fin = new FileInputStream(new File("input.txt"));

                GZIPOutputStream out = new GZIPOutputStream(new FileOutputStream(new File("out.txt")))) {

}

GZIPOutputStream里面的close会调用flush之后再调用close,但是flush会抛出异常,而编译器帮我们加的代码是fin和out的close,所以这种情况发生的时候out里面被包装的那个FileOutputStream发生了泄露,正确的做法应该是单独为每个流声明

try (FileInputStream fin = new FileInputStream(new File("input.txt"));

                FileOutputStream fout = new FileOutputStream(new File("out.txt"));

                GZIPOutputStream out = new GZIPOutputStream(fout)) {}

编译器会帮我们close fin,fout,以及out,这样所有资源就可以正确的关闭了

推荐阅读更多精彩内容