Exception和Error区别
首先：
Exception和Error继承Throwable类，在java中只有Throwable类型的实例才能被抛出(throw)或者捕获(catch)，他是异常处理机制的基本类型。
其次：
Exception和Error体现了java平台针对不同异常情况的分类。Exception是程序正常运行过程中，可以预料的意外情况，可能并且应该被捕获，并进行处理。Error正常情况下不大可能出现的情况，绝大部分的Error都会导致程序状态不正常，不可恢复，既然是非正常情况，所以不便也不需要处理，例如OutOfMemoryError之类都是Error的子类
再次：
Exception分为检查型异常和非检查型异常。检查型异常必须在源码中进行捕获处理，这是编译检查的一部分。除了RuntimeExceion及其子类之外的异常都是检查型异常。非检查型异常就是所谓的RuntimeExceion，类似NullPointerException,ArrayIndexOfBoundException就是非检查型异常，通常是可以通过编码避免的逻辑错误，具体根据需要判断是否需要捕获，编译期不检查，如果抛出了非检查型异常，那就是编码逻辑有问题，要解决。
下面两个方面要掌握：
第一、理解 Throwable、Exception、Error的设计分类，以及使用最广泛的类，以及如何自定义异常，其中有些子类最好重点理解一下，比如NoClassDefFoundErrorClassNotFoundException。
第二、理解 Java 语言中操作 Throwable 的元素和实践掌握最基本的语法是必须的，如try-catch-finally 块，throw、throws关键字等。与此同时，也要懂得如何处理典型场景。
需要遵守五个原则：
[if !supportLists]第一、[endif]
尽量不要捕获类似 Exception 这样的通用异常，而是应该捕获特定异常，这是因为在日常的开发和合作中，我们读代码的机会往往超过写代码，软件工程是门协作的艺术，所以我们有义务让自己的代码能够直观地体现出尽量多的信息，而泛泛的 Exception 之类，恰恰隐藏了我们的目的。另外，我们也要保证程序不会捕获到我们不希望捕获的异常。比如，你可能更希望 RuntimeException 被扩散出来，而不是被捕获。
进一步讲，除非深思熟虑了，否则不要捕获 Throwable 或者 Error，这样很难保证我们能够正确程序处理 OutOfMemoryError。
第二、
不要生吞（swallow）异常。这是异常处理中要特别注意的事情，因为很可能会导致非常难以诊断的诡异情况。
生吞异常，往往是基于假设这段代码可能不会发生，或者感觉忽略异常是无所谓的，但是千万不要在产品代码做这种假设！
如果我们不把异常抛出来，或者也没有输出到日志（Logger）之类，程序可能在后续代码以不可控的方式结束。没人能够轻易判断究竟是哪里抛出了异常，以及是什么原因产生了异常。
再来看看第二段代码
try {
//
业务代码
// …
} catch (IOException e) {
e.printStackTrace();
}
这段代码作为一段实验代码，它是没有任何问题的，但是在产品代码中，通常都不允许这样处理。你先思考一下这是为什么呢？
我们先来看看printStackTrace()的文档，开头就是“Prints this throwable and its backtrace to thestandard
error stream”。问题就在这里，在稍微复杂一点的生产系统中，标准出错（STERR）不是个合适的输出选项，因为你很难判断出到底输出到哪里去了。
尤其是对于分布式系统，如果发生异常，但是无法找到堆栈轨迹（stacktrace），这纯属是为诊断设置障碍。所以，最好使用产品日志，详细地输出到日志系统里。
第三、我们接下来看下面的代码段，体会一下Throw early, catch late 原则。
public void readPreferences(String fileName){
//...perform operations...
InputStream in = newFileInputStream(fileName);
//...read the preferencesfile...
}
如果 fileName 是 null，那么程序就会抛出 NullPointerException，但是由于没有第一时间暴露出问题，堆栈信息可能非常令人费解，往往需要相对复杂的定位。这个 NPE 只是作为例子，实际产品代码中，可能是各种情况，比如获取配置失败之类的。在发现问题的时候，第一时间抛出，能够更加清晰地反映问题。
我们可以修改一下，让问题“throw early”，对应的异常信息就非常直观了。
public void readPreferences(String filename) {
Objects.requireNonNull(filename);
//...perform otheroperations...
InputStream in = newFileInputStream(filename);
//...read the preferencesfile...
}
至于“catch late”，其实是我们经常苦恼的问题，捕获异常后，需要怎么处理呢？最差的处理方式，就是我前面提到的“生吞异常”，本质上其实是掩盖问题。如果实在不知道如何处理，可以选择保留原有异常的 cause 信息，直接再抛出或者构建新的异常抛出去。在更高层面，因为有了清晰的（业务）逻辑，往往会更清楚合适的处理方式是什么。
第四、有的时候，我们会根据需要自定义异常，这个时候除了保证提供足够的信息，还有两点需要考虑：
是否需要定义成 Checked Exception，因为这种类型设计的初衷更是为了从异常情况恢复，作为异常设计者，我们往往有充足信息进行分类。
在保证诊断信息足够的同时，也要考虑避免包含敏感信息，因为那样可能导致潜在的安全问题。如果我们看 Java 的标准类库，你可能注意到类似 java.net.ConnectException，出错信息是类似“ Connection
refused (Connection refused)”，而不包含具体的机器名、IP、端口等，一个重要考量就是信息安全。类似的情况在日志中也有，比如，用户数据一般是不可以输出到日志里面的。
第五、我们从性能角度来审视一下 Java 的异常处理机制，这里有两个可能会相对昂贵的地方：
[if !supportLists]· [endif]try-catch 代码段会产生额外的性能开销，或者换个角度说，它往往会影响 JVM 对代码进行优化，所以建议仅捕获有必要的代码段，尽量不要一个大的 try 包住整段的代码；与此同时，利用异常控制代码流程，也不是一个好主意，远比我们通常意义上的条件语句（if/else、switch）要低效。
[if !supportLists]· [endif]Java 每实例化一个 Exception，都会对当时的栈进行快照，这是一个相对比较重的操作。如果发生的非常频繁，这个开销可就不能被忽略了。
第六、是如何选择抛出检查型异常还是非检查型异常
１.对可恢复的情况使用检查型异常。对编程错误使用运行时异常。选择异常的主要原则是：如果期望调用者能够适当的恢复，对于这种异常就应该使用受检异常。方法中声明要抛出的每个受检异常，都是对ＡＰＩ用户的一种提示，每种异常都对应这个方法的一种可能的结果，受检异常往往指明了可恢复的条件。不符合业务逻辑抛出检查型异常，不符合ＡＰＩ规范抛出非检查型异常
２.避免不必要的使用检查型异常。如果调用者正常是有ＡＰＩ并不能阻止产生异常，并且产生异常后，使用ＡＰＩ的程序员要立刻采取恢复行动，满足这两个条件就更适合使用检查型异常
３.优先使用标准异常。好处：和程序员已经熟悉的用法一致，可读性好，降低时间开销
４.抛出与抽象相对应的异常。更高层的实现应该捕获底层的异常，同事抛出可以按照高层抽象进行解释的异常，这种做法被称为异常转译
５.努力使失败保持原子性。参数不不可变或者变化之前验证可能导致失败的部分
捕获还是抛出还要看具体的业务场景，最终的效果就是try/catch所处理的都是有意义的业务异常，而不是捕获Exception，Exception交给最外层逻辑处理不中断外部业务，则必须捕获异常进行处理，中断外部业务，不用捕获，使用最外层异常处理器处理。
常规结构：
最外层异常处理逻辑器（通用异常，公共异常，非检查型异常）
内部的异常处理try/catch仅针对有意义的检查型异常，catch之后抛出的看业务决定是中断还是非中断，或者采用逻辑处理，不抛出（必须有日志）
所以，对于部分追求极致性能的底层类库，有种方式是尝试创建不进行栈快照的 Exception。这本身也存在争议，因为这样做的假设在于，我创建异常时知道未来是否需要堆栈。问题是，实际上可能吗？小范围或许可能，但是在大规模项目中，这么做可能不是个理智的选择。如果需要堆栈，但又没有收集这些信息，在复杂情况下，尤其是类似微服务这种分布式系统，这会大大增加诊断的难度。
当我们的服务出现反应变慢、吞吐量下降的时候，检查发生最频繁的 Exception 也是一种思路。
