看看异常

从物理上，cpu上来看的话，没有任何异常机制的，是完全建模好的，按照设计意图一条一条指令执行。出现异常（总线，数学运算等）都会转入预定的异常处理流程。没有不按照指令执行的情况。

从某个其他层次来看，不按照预想的执行流程执行的情况还不少（比如申请了某些资源，忘记处理异常的时候造成流程与设计的流程不符合，导致某些资源不释放的异常）

要达到的目标是像底层cpu那样，任何的代码流程都是按照预先设计好的。

实现一个系统的时候，要明白依赖的底层系统的完全的接口（正常的接口，异常的接口）

jvm有一个异常的体系，有一个设计的异常结构和对应的语义。并且对程序极难处理的异常（OOM等）可以协助处理（打印堆信息）。

在java中，异常时按照栈往上一直抛的。这里有一些注意的点：1是按照zhan的顺序抛，而不是其他顺序（这个就是底层给模拟出来的）。抛到栈顶结束线程。

本来是A委托B，B委托C。但是出了异常的时候，就逐层网上反映：除了这种情况了，你看怎么办。

除了这种收到委托的函数给上层的异常外，还有一场是cpu底层给当前函数的。也可以说是底层的逻辑运行部件给当前逻辑单元（函数的），也可以说是一条指令其实也是一个函数（只不过这个函数是cpu的微指令来实现）给到当前执行单元的。

按照堆栈的顺序反着反应是从函数调用这种实现逻辑的方式来说异常的反馈的。其实更本质的一点是，被调用者识别到了某种不能继续的情况（比如参数不合法）或者是接收到了逻辑的实现的载体（cpu环境）反馈的异常情况而向委托者反馈的一种情形。在java中，由cpu，os，jvm共同的给搞成了异常栈这种形式。

这种按照堆栈传递的异常的整个链条都是在一个线程中考虑的。

一些业务逻辑就不管系统的异常（比如String转换为大写的时候可能就不考虑OOM之类的异常），但是一些框架逻辑考虑的一场可能就和业务的考虑不一样。同理jvm层考虑的异常和框架考虑的异常也不一样。这里说的框架比如说是一个定时任务的线程池，就不能不管业务的一些异常而直接退出。各种demo线程都是这种的。一般各种demo线程都是直接trycatch很大范围的异常的。demo一般知道自己是异常处理的最后一道门槛了，即使处理不了，也必须记录下来。一般的业务逻辑可以不处理一些异常，直接交给框架层去处理。业务处理的异常时业务能够处理的和必须处理的（比如释放业务已经申请的资源，这些资源框架不见得看得到）。

如果一个异常出现在一个申请了很多资源的session中的一个步骤的时候，那应该给使用者告知相应的异常，使用者积极的处理。还有一种情况是，实现一个系统的时候，先把各个小功能实现了（里面涉及各种异常处理），然后一种中间的模块调用各个小模块，中间的模块就不用处理异常了，直接的可以和小模块通过正常的委托接口通信了。相当于把其他子系统的一场接口封装并转化为本系统的交互方式了。（这里各个小功能也可以抛出系统内自建的异常，但和其他系统的异常就不在这个系统中继续传播和处理了）。这是2中异常激昂处理中常见的小场景。一般而言感觉就是这种形式比较好了。框架一般不知道业务异常（即框架和业务额一场一定要设计好，比如业务的npe抛出来给框架根本也没什么意义。）总的来说就是利用其他系统实现一个系统的时候，先分割小系统，处理各个外部模块或者系统的异常，形成本系统的异常体系或者消灭掉异常，然后由指挥者利用构建好的小系统来实现整个系统。给其他系统抛的异常属于系统接口的一个部分，一定不能抛出对其他系统没有意义的异常（无法处理）。

    出现系统的异常的时候，一般也是没啥办法，直接不处理（所以有些异常在java里建模成了unchecked异常）

    附java异常结构

    c语言要自己实现异常，有些特殊手段，比如接收操作系统信号，lognjmp，goto