如何管控好自己的Exception

写这篇文章之前，考虑了一下，因为比较基础，并且网上资料也很多。但是因为其地位比较重要，还是和大家分享下自己在项目里的心得体会

本篇文章主要关注点，自定义异常和异常链，以及项目里异常和日志的结合使用

异常：异于常规的不合理反应

首先我们来看下JAVA的异常体系架构

图片发自App

从这张图我们看到异常的鼻祖是Throwable,它有两个子类，Error,Exception.

Error类发生的原因来自于系统层面，是超越了程序的管控。但是不代表我们束手无策，起码给予我们一个问题追溯的方向。在这里我把项目经常遇到的异常简单分析下。OutOfMemory是我们经常遇到的，这类异常出现以后，如果对于一个系统代码量在大几十万行的情况下去追溯是相当困难的。所以我们要保持冷静去思考，导致内存溢出的原因，内存资源不足以及不合理的代码导致两方面分析。

内存资源不足，一般出现情况比较少，原因是对于一个新搭建的系统来说，我们应用服务器的内存按照如今的配置，都是满足我们的实际应用。但是随着应用服务器负载越来越重时，我们就需要考虑内存的扩容，或者搭建应用服务器的集群等来均摊压力。因为随着业务量的递增，系统复杂度增加到一定程度时，即使我们的代码优化程度合理，也会出现内存不足。这时候我们需要从配置和扩容两个层面着手考虑。这需要根据实际情况定夺。

基于内存合理的情况下，我们需要更多的关注我们的代码合理性，因为这是我们作为开发人员更能够把控的一面。出现这样的问题，我们需要去关注我们的大数据量一次读取，这个问题比较隐蔽，所以上线之初我们很难发现，以及循环体频繁的创建对象，却又无法及时的释放。这是在项目里我们经常会碰见的。如何解决？

在我们日常的代码开发过程中，需要我们着力每一个查询，规避全表一次读取，是否考虑分页。是否会出现死循环或者递归调用而引发的频繁创建对象，是否使用完后及时释放，当然这份回收工作是JVM当中的守护线程GC帮我们去做的事情。但是有一点，当我们创建的频次远远高于GC回收时，依然会内存泄露。所以需要我们对代码有一种发自内心的敬畏。当然，我在这点也做的不够好，需要不断努力。

ThreadDead,Can not create native Thread等，这两类异常遇到过。在我们当时使用自定义线程池时，用完没有及时释放，导致服务器挂掉。

所以综上所述，Error类的异常一出现基本就是致命的。作为开发者，敬畏每一个对象，每一行代码，每一段逻辑处理。

下面我们使用最多的算是RuntimeException,它又属于非检查类的异常，非检查异常和检查异常最直接的区别就是，检查异常必须要补获或者必须要抛出。否则编译器都不答应。

自定义异常是我们经常遇到的，区别于RuntimeException,在实际项目里，由于我们的系统业务复杂，代码的健壮性又并非接近完美，所以我们需要为自己解脱，定义自定义异常，个人认为，就是业务异常。其他的我们可以继承RuntimeException。

异常补获？

异常补获，在实际当中是最容易出现的问题点，就是补货的时机，以及补获之后向上层反馈的方式。这是我们最容易出现的问题。补获时机：往往在事物层，我们出现了补获异常，导致事物不回滚，造成了数据不一致性。向上层反馈，需要我们事先必须清楚我们的调用方是谁？外围系统还是本系统的服务调用，或者是前端。如果涉及到外围和前端，我们一定不能直接抛，这里无论是检查异常还是非检查异常。怎么做，我们需要转化我们的自定义异常再去抛出。否则你就很不专业了。那问题来了，这种异常转化抛出后，如何定位，这时候需要和我们的日志结合使用了，帮助我们来定位问题。日志我会在后面的文章当中专门做一期专题。

异常链

简单来说，就是异常需要封装和传递

定义一个异常类继承Exception类，然后根据需要定义我们需要传参的构造方法，在构造方法里去调用父类的构造方法

然后进行传递   

try{ //DoSomethind }catch(Exceptione){

//这种形式也可以叫异常转译，调用者获得该异常后在调用getCause()方法即可获得Exception的异常信息，如此即可以方便查找异常的根本信息，便于解决问题。

      thrownew IOException(e);

}