1，unchecked Exception(不检查异常),运行时异常，例如NullPointerException,ArrayIndexOutOfBondsException.可以编码避免的逻辑错误。具体根据需要判断是否需要捕获，并不会在编译期强制要求。
2, checked Exception 可检查异常在源代码是必须显示地进行捕获处理，这是编译期检查的一部分。
3, 实践经验小结。
a,上传，下载不能抛异常（如果抛出异常，程序都“断了”，这其实是一个错误，哪怕下载了一个空文档也比抛出异常强）。上传，下载finally中必须关流。
b,尽量不捕获类似Exception这样的异常，范围太大，无法定位具体的原因。
c,不要生吞异常。基于假设这段代码可能不会发生，或者感觉忽略异常是无所谓的，但是不要在产品代码做这样的假设。（避免主观意识：我觉得好像不会产生什么异常之类的）。
d,程序是算法加数据结构。程序有正常的，有异常的，有错误的。
e,异常不是错误。错误一般来说都是JVM不正常了。内存溢出错误，堆栈溢出错误。而异常更多是可控的，可能由于程序中的某些原因（逻辑，数据）造成的。可以避免，可以捕获，但是捕获到一定要进行处理。
4， 相对昂贵地方。
a,try--catch，往往会影响JVM对代码进行优化。最好仅捕获必要的代码段。
b,利用异常控制代码流程，也不是一个好主意。因为远比，if/else；switch；break;continue低效。
c，Java每实例化一个Exception，都会对当时栈进行快照，这是一个相对比较重的操作。
5, 问题思考。
a,服务出现反应变慢，吞吐量下降的时候，检查发生最频繁的Exception也是一种思路。
b,层层抛出异常。代码调用结构是否美观？
6， 注意事项。
a,一个函数尽管抛出了多个异常，但是只有一个异常可被传播到调用段。
b,不要在finally代码块中处理返回值。
c,如果没有这个必要，就不要使用异常。但是又不可能不用。这是不可能的。
d,千万不要将异常用于控制流。
e,异常结构代码与程序控制流关系。异常结构代码中有break,return,continue。应该如果注意这些情况发生，如果有这样代码，如果准确定位错误（如果出现错误）。
7， 新概念。
a,反应式编程。是异步的，基于事件的，所以异常肯定不能直接抛出的。如果直接抛出，随便一个异常引起程序崩溃，影响后续处理。