网站正在建设中视频,wordpress加载本地媒体,没有公司 接单做网站,wordpress主题原创原标题#xff1a;Java异常处理最佳实践及陷阱防范出自《深夜里的程序猿》作者#xff1a;wangzenghuang前言不管在我们的工作还是生活中#xff0c;总会出现各种“错误”#xff0c;各种突发的“异常”。无论我们做了多少准备#xff0c;多少测试#xff0c;这些异常总会…原标题Java异常处理最佳实践及陷阱防范出自《深夜里的程序猿》作者wangzenghuang前言不管在我们的工作还是生活中总会出现各种“错误”各种突发的“异常”。无论我们做了多少准备多少测试这些异常总会在某个时间点出现如果处理不当或是不及时往往还会导致其他新的问题出现。所以我们要时刻注意这些陷阱以及需要一套“最佳实践”来建立起一个完善的异常处理机制。正文异常分类首先这里我画了一个异常分类的结构图。在JDK中Throwable是所有异常的父类其下分为”Error“和”Exception“。Error意味着出现了不可控的严重错误例如OutOfMemoryError。Exception则细分为两类受检异常(check)需要我们手动try/catch或者在方法定义中throws编译器在编译的时候会检查其合法性。非受检异常(uncheck)则不需要我们提前处理。这些简单的概念对于开发人员来说都是必须掌握的这里就展示个图例不做详细的描述了我们的”正餐“还在后面。重新认识try/catch/finally说到异常处理这里就不得不提try/catch/finally。try不可以单独存在要么搭配catch要么搭配finally或者三者并存。1、try代码块监视代码块的执行发现对应的的异常则跳转至catch若无catch则直接到finally块。2、catch代码块发生对应的异常会执行里面的代码要么处理要么向上抛出。3、finally代码块:不管是否有异常都必执行一般用来清理资源释放连接等。然而有以下几种情况不会执行到这里的代码。代码执行流程未进入try代码块。代码在try代码块中发生死循环、死锁等状态。在try代码块中执行了System.exit()操作。try/catch/finally陷阱下面介绍两个我们在使用tcf的时候可能会遇到的陷阱。代码1public class TCFDemo {public static void main(String[] args) {//11System.out.println(returnVal());}static int returnVal(){int a 1;int b 10;try{return a;}finally {return b;}}}陷阱1在finally中添加return语句这样会覆盖掉try代码return的值假如业务逻辑比较复杂这里是很容易掉坑的不利于排查错误。代码2public class TCFDemo {public static void main(String[] args) {Lock lock new ReentrantLock();try{//有可能加锁失败lock.lock();//dost}finally {lock.unlock();}}}陷阱2由于lock方法在加锁的时候有可能会抛出Uncheck异常如果在try代码块中必然会执行unlock方法此时由于并没有加锁成功所以会抛出IllegalMonitorStateException这样一来后者的异常就覆盖掉了前者加锁失败的异常信息所以我们应该把加锁的方法挪至try代码块外面。最佳实践好了前面简单介绍了异常的分类以及try/catch/finally的注意事项现在可以总结一下我们在异常处理的时候有哪些”最佳实践“了。当需要向上抛出异常的时候需根据当前业务场景定义具有业务含义的异常优先使用行业内定义的异常或者团队内部定义好的。例如在使用dubbo进行远程服务调用超时的时候会抛出DubboTimeoutException而不是直接把RuntimeException抛出。请勿在finally代码块中使用return语句避免返回值的判断变得复杂。捕获异常具体的子类而不是Exception更不是throwable。这样会捕获所有的错误包括JVM抛出的无法处理的严重错误。切记更别忽视任何一个异常(catch住了不做任何处理)即使现在能确保不影响逻辑的正常运行但是对于将来谁都无法保证代码会如何改动别给自己挖坑。不要使用异常当作控制流程来使用这是一个很奇葩也很影响性能的做法。清理资源释放连接等操作一定要放在finally代码块中防止内存泄漏如果finally块处理的逻辑比较多且模块化我们可以封装成工具方法调用代码会比较简洁。结尾小小的异常有大大的学问你觉得呢?返回搜狐查看更多责任编辑
