前言
Java 语言在设计之初就提供了相对完善的异常处理机制，这也是 Java 得以大行其道的原因之
一，因为这种机制大大降低了编写和维护可靠程序的门槛。如今，异常处理机制已经成为现代编
程语言的标配。但是Exception与Error有什么区别呢?
区别
一.Error
虚拟机生成并抛出，大多数错误与代码编写者所执行的操作无关。例如，Java虚拟机运行错误（Virtual
MachineError），当JVM不再有继续执行操作所需的内存资源时，将出现 OutOfMemoryError。这些异常发生时，Java虚拟机（JVM）一般会选择线程终止；还有发生在虚拟机试图执行应用时，如类定义错误（NoClassDefFoundError）、链接错误（LinkageError）。这些错误是不可查的，因为它们在应用程序的控制和处理能力之 外，而且绝大多数是程序运行时不允许出现的状况。对于设计合理的应用程序来说，即使确实发生了错误，本质上也不应该试图去处理它所引起的异常状况。在Java中，错误通常是使用Error的子类描述。如 OutOfMemoryError 之类，都是 Error 的子类。
二.Exception
分为可检查（checked）异常和不检查（unchecked）异常。
1. 检查性异常：最具代表的检查性异常是用户错误或问题引起的异常，这是程序员无法预见的。
RuntimeException之外的异常我们统称为非运行时异常，从程序语法角度讲是必须进行处理的异常，如果不处理，程序就不能编译通过。
2. 非检查性异常：与检查性异常相反，运行时异常可以在编译时被忽略。
在Exception分支中有一个重要的子类RuntimeException（运行时异常），该类型的异常自动为你所编写的程序定义ArrayIndexOutOfBoundsException（数组下标越界）、NullPointerException（空指针异常）、ArithmeticException（算术异常）、MissingResourceException（丢失资源）、ClassNotFoundException（找不到类）等异常，这些异常是不检查异常，程序中可以选择捕获处理，也可以不处理。这些异常一般是由程序逻辑错误引起的，程序应该从逻辑角度尽可能避免这类异常的发生
注意事项
- 尽量不要捕获类似 Exception 这样的通用异常，而是应该捕获特定异常。不要捕获 Throwable 或者 Error，这样很难保证我们能够正确程序处理 OutOfMemoryError。
- try中的代码块不宜过长，捕获时不宜大而全，finally里只释放资源不要有业务逻辑，尤其是修改返回值。finally中的代码始终是执行的，用途为清理资源
- 性能方面:try-catch 代码段会产生额外的性能开销，或者换个角度说，它往往会影响 JVM 对代码进行优化，所以建议仅捕获有必要的代码段，尽量不要一个大的 try 包住整段的代码；与此同时，利用异常控制代码流程，也不是一个好主意，远比我们通常意义上的条件语句（if/else、switch）要低效。Java 每实例化一个 Exception，都会对当时的栈进行快照，这是一个相对比较重的操作。如果发生的非常频繁，这个开销可就不能被忽略了。
- 在保证诊断信息足够的同时，也要考虑避免包含敏感信息，因为那样可能导致潜在的安全问题。如果我们看 Java 的标准类库，你可能注意到类似 java.net.ConnectException，出错信息是类似“ Connection refused (Connection refused)”，而不包含具体的机器名、IP、端口等，一个重要考量就是信息安全。类似的情况在日志中也有，比如，用户数据一般是不
可以输出到日志里面的。 - 不要生吞异常（忽略异常）。这是异常处理中要特别注意的事情，因为很可能会导致非常难以诊断的诡异情况。
如果我们不把异常抛出来，或者也没有输出到日志（Logger）之类，程序可能在后续代码以不可控的方式结束。没人能够轻易判断究竟是哪里抛出了异常，以及是什么原因产生了异常。这段代码是没有任何问题的，但是在产品代码中，通常都不允许这样处理。因为在稍微复杂一点的生产系统中，标准出错不是个合适的输出选项，因为你很难判断出到底输出到哪里去了。如果发生异常，但是无法找到堆栈轨（stacktrace），这纯属是为诊断设置障碍。所以，最好使用产品日志，详细地输出到日志系统里。
try {
// 业务代码
} catch (IOException e) {
e.printStackTrace();
}总结
异常的出现让我们编写的程序运行起来更加的健壮，同时为程序在调试、运行期间发生的一些意外情况，提供了补救机会；即使遇到一些严重错误而无法弥补，异常也会非常忠实的记录所发生的这一切。