28 | 异常和中断：程序出错了怎么办？

文中“而是更像两个不同的独立进程之间在 CPU 层面的切换，所以这个过程我们称之为上下文切换（Context Switch）。”，那么，上下文就是运行在cpu层面的一个独立的进程？

有个疑问，软件层面的错误可以通过捕获-处理这样的流程解决。但是硬件难道永远不会出错吗，比如门电路输出有误，电压不足...等外部因素。换句话说 cpu计算的结果一定是正确的吗？

linux内核中有软中断和硬中断的说法。比如网卡收包时，硬中断对应的概念是中断，即网卡利用信号“告知”CPU有包到来，CPU执行中断向量对应的处理程序，即收到的包拷贝到计算机的内存，然后“通知”软中断有任务需要处理，中断处理程序返回；软中断是一个内核级别的进程（线程），没有对应到本次课程的概念，用于处理硬中断余下的工作，比如网卡收的包需要向上送给协议栈处理。

网上搜到的思考题答案，分享给大家： 硬中断由与系统相连的外设(比如网卡、硬盘)自动产生的。主要是用来通知操作系统系统外设状态的变化。 软中断是一组静态定义的下半部分接口，可以在所有的处理器上同时执行，即使两个类型相同也可以。但是一个软中断不会抢占另外的一个软中断，唯一可以抢占软中断的硬中断。 为了满足实时系统的要求，中断处理应该越快越好。编写驱动程序的时候，一个中断产生之后，内核在中断处理函数中可能需要完成很多工作。但是中断处理函数的处理是关闭了中断的。也就是说在响应中断时，系统不能再次响应外部的其它中断。这样的后果会造成有可能丢失外部中断。于是，linux内核设计出了一种架构，中断函数需要处理的任务分为两部分，一部分在中断处理函数中执行，这时系统关闭中断。另外一部分在软件中断中执行，这个时候开启中断，系统可以响应外部中断。 Linux为了实现这个特点，当中断发生的时候硬中断处理那些短时间，就可以完成的工作，而将那些处理事件比较长的工作，放到中断之后来完成，也就是软中断(softirq)来完成。

硬中断类似键鼠，网卡这些外接设备发出的中断请求，同比与上文的中断。 软中断类似程序内部IO的操作，由程序内部发出中断请求，同比上文的陷阱。

有点疑问，文中说“故障异常经异常处理程序处理之后会回到故障发生的指令位置，并再执行一次”，并还举例说加法溢出是故障异常，既然按这例子讲，难道再加一次就不会异常了吗？这可能会无限陷入故障异常的死胡同？

老师，请问java语言中的try..catch翻译成机器语言时是不是就是向异常表中注册了异常码？ 另外，开发规范中说try..catch不要写在for循环里面，是不是因为以下两点？： 1.for循环里try..catch会导致多次注册异常表？ 2.一旦for循环里面的代码发生异常，如果try..catch写在for循环里面，在执行catch异常处理前会发生[保存现场+上下文切换]，catch异常处理完成之后上下文切换回来，继续执行for循环里的代码通常情况下可能会再次引发异常处理。而如果放在for循环外层，一旦发生异常，异常处理完毕，则会继续执行后面的代码逻辑。 望解答，谢谢老师！

这一讲，我给你讲了计算机里的“异常”处理流程。这里的异常可以分成中断、陷阱、故障、中止这样四种情况。这四种异常，分别对应着 I/O 设备的输入、程序主动触发的状态切换、异常情况下的程序出错以及出错之后无可挽回的退出程序。 当 CPU 遭遇了异常的时候，计算机就需要有相应的应对措施。CPU 会通过“查表法”来解决这个问题。在硬件层面和操作系统层面，各自定义了所有 CPU 可能会遇到的异常代码，并且通过这个异常代码，在异常表里面查询相应的异常处理程序。在捕捉异常的时候，我们的硬件 CPU 在进行相应的操作，而在处理异常层面，则是由作为软件的异常处理程序进行相应的操作。 而在实际处理异常之前，计算机需要先去做一个“保留现场”的操作。有了这个操作，我们才能在异常处理完成之后，重新回到之前执行的指令序列里面来。这个保留现场的操作，和我们之前讲解指令的函数调用很像。但是，因为“异常”和函数调用有一个很大的不同，那就是它的发生时间。函数调用的压栈操作我们在写程序的时候完全能够知道，而“异常”发生的时间却很不确定。所以，“异常”发生的时候，我们称之为发生了一次“上下文切换”（Context Switch）。这个时候，除了普通需要压栈的数据外，计算机还需要把所有寄存器信息都存储到栈里面去。

软中断，顾名思义，就是程序在执行的过程中所发生的异常，对应的是异步 硬中断，顾名思义，就是程序的异常来自于外部的系统，而不是正在执行的程序，对应的是同步

老师请问一下， 是不是无论哪种异常发生都会有一次上下文切换？