Exception和Error有什么区别

        Exception和Error都继承了Throwable类，在java中只有Throwable类型的实例才可以被抛出（throw）或者捕获（catch），它是异常处理机制的基本组成类型。

        Exception和Error体现了java平台设计者对不同异常情况的分类。

        Exception是程序正常运行中，可以预料的意外情况，可能并且应该被捕获，进行相应处理。

        Error是指在正常情况下，不大可能出现的情况，绝大部分Error都会导致程序（比如JVM自身）处于非正常的、不可恢复的状态。既然是非正常情况，所以不便于也不需要捕获，常见的比如OutOfMemoryError之类，都是Error的子类。

        Exception又可分为可检查异常和不检查异常，可检查异常在源代码里必须显示地进行捕获处理，这是编译期检查的一部分。前面我介绍的不可检查的Error，是Throwable不是Exception。

        不检查异常就是所谓的运行时异常，类似NullPointerException、ArrayIndexOutOfBoundsException之类，通常是可以编码避免的逻辑错误，据图根据需要来判断是否需要捕获，并不会在编译期强制需求。

        前面谈的大多是概念性的东西，下面来谈一谈实践中的选择。

先看第一段代码：

try{

//业务代码

//...

Thread.sleep(1000L);

}catch(Exception e){

//Ignore it

}

这段代码虽然很短，但是已经违反了异常处理的两个基本原则。

第一，尽量不要捕获类似Exception这样的通用异常，而是应该捕获特定异常，在这里是Thread.sleep()跑出的InterruptedException。

这是因为在日常的开发和合作中，我们读代码的机会往往超过写代码，软件工程是门协作的艺术，所以我们有义务让自己的代码能够直观地体现出尽量多的信息，而泛泛的Exception之类，恰恰隐藏了我们的目的。另外，我们也要保证程序不会捕获到我们不希望捕获的异常。比如，你可能更希望RuntimeException被扩散出来，而不是被捕获。进一步讲，除非深思熟虑了，否则不要捕获Throwable或者Error，这样很难保证我们能够正确处理OutOfMemoryError.

第二，不要生吞异常。这是异常处理中要特别注意的事情，因为很可能会导致非常难以诊断的诡异情况。

生吞异常，往往是基于假设这段代码可能不会发生，或者感觉忽略异常时无所谓的，但是千万不要在产品代码做这种假设！

如果我们不把异常跑出来，或者也没有输出到日志之类，程序可能在后续代码以不可控的方式结束。没人能够轻易判断究竟是哪里抛出了异常，以及是什么原因产生了异常。

再来看看第二段代码

try{

//业务代码

//...

}catch(IOException e){

e.printStackTrace();

}

这段代码作为一段实验代码，它是没有任何问题的。但是在产品代码中，通常都不允许这样处理。

为什么呢？

我们先来看看printStackTrace()的文档，开头就是“Prints this throwable and its backtrace to the standard error stream"。问题就在这里，在稍微复杂一点的生产系统中，标准出错不是个合适的输出选择，因为你很难判断出到底输出到哪里去了。

尤其是对于分布式系统，如果发生异常，但是无法找到堆栈轨迹，这纯属是为诊断设置障碍。所以，最好使用产品日志，详细的输出到日志系统里。

我们接下来看下面的代码段，体会一下Throw early,catch late原则。

public void readPreferences(String fileName){

        //...perform operations...

        InputStream in = new FileInputStream(fileName);

        //...read the preferences file...

}

如果fileName是null，那么程序就会抛出NullPointerException，但是由于没有第一时间暴露出问题，堆栈信息可能非常令人费解，往往需要相对复杂的定位。这个NPE只是作为例子，实例产品代码中，可能是各种情况，比如获取配置失败之类的。在发现问题的时候，第一时间抛出，就能更加清晰地反映问题。

我们可以修改一下，让问题“throw early：，对应的异常信息就非常直观了。

public void readPreferences(String fileName){

        Objects.requireNonNull(fileName);

        //...perform other operations...

        InputStream in = new FileInputStream(fileName);

        //...read the perferences file...

}

至于“catch late”。其实是我们经常苦恼的问题，捕获异常后，需要怎么处理呢？最差的处理方式，就是我前面提到的”生吞异常“，本质上其实是掩盖问题。如果实在不知道如何处理，可以选择保留原有异常的cause信息，直接再抛出或者构建新的异常抛出去。在更高层面，因为有了清晰地（业务）逻辑，往往会更清楚合适的处理方式是什么。

有的时候，我们会根据需要自定义异常，这个时候除了保证提供足够的信息，还有两点需要考虑：

一、是否需要定义成Checked Exception，因为这种类型设计的初衷更是为了从异常情况恢复，作为异常设计者，我们往往有充           足信息进行分类；

二、在保证诊断信息足够的同时，也要考虑避免包含敏感信息，因为那样可能导致潜在的安全问题。如果我们看java类库，你可         能注意到类似java.net.ConnectExcetion，出错信息是类似“Connection refused(Connection refused)"，而不包含具体的机器         名、IP、端口号等，一个重要考量就是信息安全。类似的情况在日志中也有，比如，用户数据一般是不可以输出到日志里面         的。

业界有一种争论（甚至可以算是某种程度的共识），java语言的Checked Exception也许是个设计错误，反对者列举了几点：

一、Checked Exception的假设是我们捕获了异常，然后恢复程序。但是，其实我们大多数情况下，根本就不可能恢复。                     Checked Exception的使用，已经大大偏离了最初的设计目的。

二、Checked Exception不兼容functional编程，如果你写过Lambda/Stream代码，相信深有体会。

许多开源项目，已经采纳了这种实践，比如Sping、Hibernate等，甚至反映在新的编程设计中，比如Scala等。如果感兴趣，你可以参考：http://literatejava.com/exceptions/checked-exceptions-javas-biggest-mistake/。

当然，很多人也觉得没有必要矫枉过正，因为确实有一些异常，比如和环境相关的IO、网络等，其实是存在可恢复性的，而且java已经通过业界的海量实践，证明了其构建高质量软件的能力。

我们从性能角度来审视一下java的异常处理机制，这里有两个可能会相对昂贵的地方：

一、try-catch 代码段会产生额外的性能开销，或者换个角度讲，它往往会影响JVM对代码进行优化，所以建议仅捕获有必要的代         码段，尽量不要一个大的try包裹整段的代码；与此同时，利用异常控制代码流程，也不是一个好主意，远比我们通常意义上         的条件语句（if/else、switch）要低效。

二、java每实例化一个Exception，都会对当时的栈进行快照，这是一个相对比较重的操作。如果发生的比较频繁，这个开销就           不能被忽略了。

所以，对于部分追求极致性能的底层类库，有种方式是尝试创建不进行栈快照的Exception。这本身也存在争议，因为这样做的假设在于，我创建异常时知道未来是否需要堆栈。问题是，实际上可能吗？小范围或许可能，但是在大规模项目中，这么做可能不是个理智的选择。如果需要堆栈，但又没有收集这些信息，在复杂情况下，尤其是类似微服务这种分布式系统，这会大大增加诊断的难度。

当我们的服务出现反应变慢、吞吐量下降的时候，检查发生最频繁的Exception也是一种思路。