一、引言
处理器的速度跟外围硬件设备的速度往往不在一个数量级上，因此，如果内核采取让处理器向硬件发出一个请求，然后专门等待回应的办法，显然差强人意。既然硬件的响应这么慢，那么内核就应该在此期间处理其他事务，等到硬件真正完成了请求的操作之后，再回过头来对它进行处理。想要实现这种功能，轮询(polling)可能会是一种解决办法。可以让内核定期对设备的状态进行查询，然后做出相应的处理。不过这种方法很可能会让内核做不少无用功，因为无论硬件设备是正在忙碌着完成任务还是已经大功告成，轮询总会周期性地重复执行。更好的办法是由我们来提供一种机制，让硬件在需要的时候再向内核发出信号(变内核主动为硬件主动)，这就是中断机制。
众所周知，在C++中有着较为完善的异常处理机制，同样在C语言中也有很不错的异常处理机制来支持，另外在其它许多现代编程语言中，也都有各自的异常处理编程机制，如Ada语言等。但我们更应该知道这些编程语言所提供的异常处理机制的实现，都是建立在操作系统中所提供的异常处理机制之上，如Windows平台上的VC编译器所实现的C++异常处理模型，它就是建立在SEH机制之上的。如果没有采用这种方式，比如Linux操作系统上的gcc就没有采用到操作系统中所提供的异常处理机制，这样就会有一个很大的缺点，那就是对于应用程序的开发者而言，它不能够很好在自己的应用程序中，来有效控制操作系统中所出现的一些意外的系统异常，例如程序执行过程中可能出现的段错误，被零除等计算异常，以及其它许多不同类型的系统异常等。所以Linux操作系统上的gcc编译的程序中，它只能捕获程序中，曾经被自己显式地抛出来的异常，而对于系统异常，catch block则毫无办法。
因此，操作系统平台中所提供的中断、异常处理机制是非常有必要的。它除了能够帮助开发人员发现和解决软件中的错误外，还被广泛应用于软件保护技术、软件漏洞利用等方面。因此，深入研究中断、异常处理机制的原理和实现以扩展其应用的范围是有必要的。
二、中断处理方式
Ⅰ、WINDOWS系统的中断处理方式
Windows内核对于中断使用了陷阱派发机制，它使用中断陷阱处理器来响应设备的中断，中断陷阱处理器或者将控制权给负责处理中断的外部例程（中断服务程序，ISR），或者传递给一个响应该中断的内部内核例程。设备驱动程序提供了ISR来处理设备中断，内核为其他类型的中断提供了ISR。
Windows的中断主要有硬件中断和软件中断，通过Windows核心我们可以禁止软件中断和硬件中断。软件中断主要引发对线程的调度以及以异步方式打断一个线程执行的机制。而硬件中断主要是为了实现处理器和设备并行工作。对于硬件中断，Windows 将硬件中断转化为能够触发执行的驻留在不同虚拟机中的ISR（中断服务程序）事件，这是一个较好的中断处理方法。下面我们来讨论一下Windows 系统的硬件终端处理机制。
在Windows系统下，处理器可以在不同的状态（V86、实模式和保护模式）下运行。当DOS运行时，则处理器运行V86模式。当Windows 执行时或当DOS VM已经切换进保护模式时，处理器则运行Ring3保护模式。当VMM（虚拟机管理器）或VXD （虚拟设备驱动程序）执行时，处理器则运行在Ring0 保护模式。在Windows系统环境中，Windows将所有的IDT入口指向VMM 中的一个函数。VMM会判断出来自
IDT入口项的调用是作为异常被调用还是作为中断被调用。VMM本身负责处理异常而将所有硬件中断交给一个名为VPICD（虚拟可编程中断控制器设备）的VXD。如果某个VXD 已经为某个硬件中断注册了中断处理函数，那么VPICD 就将中断传递给该VXD。如果没有，VPICD 将把某个中断传递给某个VM，这一过程被称作“中断反射”。
VXD通过调用VPICD的VPICD_Viutualize_IRQL 服务函数为特定的硬件中断
注册并将回调函数传递给VPICD。一旦VXD 已经为中断注册，它将作为一个真正的中断处理器，为中断设备进行中断服务，同时VXD 可能使用另一个VPICD 服务函数VPICD_Set_Int_Request来把中断映射到VM，让VM 的中断处理函数来提供服务。
从IDT 到VXD 中断处理函数的途径
在使用中断服务时，我们也要对下列情况进行注意。
1、中断响应时间：为了实现实时操作，一般要求中断响应时间尽可能的短。由于硬件中断的响应过程比较复杂，中断响应时间通常在1ms 以上。为了使中断响应时间最短，硬件中断的处理应在VXD 中进行。但即使在VXD 中进行，VXD 也不能保证对硬件中断的实时响应。原因在于ring 转换以及VMM 和VPICD之间存在多个层次的联系。
2、中断结束处理（EOI）：在编写中断处理函数时，常见的错误是忘记EOI，导致一个硬件中断仅被调用一次。虽然设备本身能产生更多的中断，但是PIC（可编程中断控制器）不让这些中断到达处理器，并会一直持续到PIC 接受到EOI 为止。Windows 使用与DOS 不同的中断控制器的EOI机制。VPICD 是被中断通知的第一个VXD，然后VPICD 立即发送“特定EOI”到控制器。然后VPICD 屏蔽控制器上的中断级别。这两个操作使得其他的中断级别可以被识别，包括那些比正在中断的级别低的优先权。当VXD 在退出中断处理函数前调用VPICD_Phys_EOI 服务函数时，VPICD 将清除相同级别上的中断的屏蔽。
3、内存管理：处理硬件中断的驱动程序对所有分配的内存有严格的要求。所有在中断期间要访问的代码和数据都必须是固定的、页码锁定的和不可废弃的。这包括中断处理函数本身的代码以及在中断处理过程中要用到的驱动程序代码段、任何动态分配的缓冲区和应用程序分配的要传递给驱动程序的缓冲区。内存要求必须是固定的。因为内存管理器把中断处理函数要用到的数据段移动了，在一些字节被拷贝后，硬件中断发生，这时硬件中断处理函数被执行。硬件中断处理函数会更新正在移动的数据段中的一些内容，当处理函数结束运行之后，内存管理器接着移动数据段，而这时的数据段已经被处理函数更改过了。内存管理器并不知道处理函数已经改变了数据。而使用该数据段的应用程序就得不到希望得到的数据。同时内存又要求必须是页面锁定的。假设硬件中断发生了，而内存管理器是在可废弃的代码中，那么就会发生段不在内存中的警告，在此种情况下
就有可能发生重入DOS 的情况，而DOS 代码是不可重入的，所以代码段是不可废弃的。
Ⅱ、LINUX系统的中断处理方式
当一个中断发生时，并不是所有的操作都具有相同的急迫性。事实上，把所有的操作都放进中断处理程序本身并不合适。需要时间长的、非重要的操作应该推后，因为当一个中断处理程序正在运行时，相应的IRQ 中断线上再发出的信号就会被忽略。另外中断处理程序不能执行任何阻塞过程，如I/O 设备操作。因此，Linux 把一个中断要执行的操作分为下面的三类：
1、紧急的（Critical）
这样的操作诸如：中断到来时中断控制器做出应答，对中断控制器或设备控制器重新编程，或者对设备和处理器同时访问的数据结构进行修改。这些操作都是紧急的，应该被很快地执行，也就是说，紧急操作应该在一个中断处理程序内立即执行，而且是在禁用中断的状态下。
2、非紧急的（Noncritical）
这样的操作诸如：修改那些只有处理器才会访问的数据结构（例如，按下一个键后，读扫描码）。这些操作也要很快地完成，因此，它们由中断处理程序立即执行，但在启用中断的状态下。
3、非紧急可延迟的（Noncritical deferrable）
这样的操作诸如：把一个缓冲区的内容拷贝到一些进程的地址空间（例如，把键盘行缓冲区的内容发送到终端处理程序的进程）。这些操作可能被延迟较长的时间间隔而不影响内核操作，有兴趣的进程会等待需要的数据。
尽管分为上述的三种，但所有的中断处理程序都执行四个基本的操作：1、在内核栈中保存IRQ 的值和寄存器的内容；2、给与IRQ 中断线相连的中断控制器发送一个应答，这将允许在这条中断线上进一步发出中断请求；3、执行共享这个IRQ 的所有设备的中断服务例程（ISR）；4、跳到ret_to_usr( )的地址后终止。
Linux系统的中断主要有3种组织形式：
1、IRQ 描述符irq_desc：对于每个IRQ 中断线，Linux 都用一个irq_desc_t 数据结构来描述，我们把它叫做IRQ 描述符，NR_IRQS 个IRQ 形成一个全局数组irq_desc[]，其定义在/include/linux/irq.h 中。
2、中断控制器描述符irq_chip：由于CPU 不同，故每个处理器对于中断的处理方式不一样。Linux 为了实现统一的中断处理，提供了底层的中断处理抽象接口，对于每个平台都需要实现底层的接口函数。这样对于上层的中断通用处理程序就无需任何改动。
3、中断服务例程描述符irqaction：在IRQ 描述符中我们看到指针action 的结构为irqaction，它是为多个设备能共享一条中断线而设置的一个数据结构，代表了每个注册中断对应的信息，其在include/linux/interrupt.h 中定义。
下面我们来具体讨论一下中断过程。当外设的驱动程序都已完成了初始化工作，并且已把相应的中断服务例程挂入到特定的中断请求队列，同时当前进程正在用户空间运行（随时可以接受中断），且外设已产生了一次中断请求，CPU 就在执行完当前指令后来响应该中断。
中断处理系统在 Linux 中的实现是非常依赖于体系结构的，实现依赖于处理器、所使用的中断控制器的类型、体系结构的设计及机器本身。设备产生中断，通过总线把电信号发送给中断控制器。如果中断线是激活的，那么中断控制器就
会把中断发往处理器。在大多数体系结构中，这个工作就是通过电信号给处理器的特定管脚发送一个信号。除非在处理器上禁止该中断，否则，处理器会立即停止它正在做的事，关闭中断系统，然后跳到内存中预定义的位置开始执行那里的代码。这个预定义的位置是由内核设置的，是中断处理程序的入口点。
对于 ARM 系统来说，有个专用的IRQ 运行模式，有一个统一的入口地址。假定中断发生时CPU 运行在用户空间，而中断处理程序属于内核空间，因此，要进行堆栈的切换。也就是说，CPU 从TSS 中取出内核栈指针，并切换到内核栈（此时栈还为空）。对于在Linux系统，如果当前处于内核空间时，对于 ARM 系统来说是处于SVC 模式，此时产生中断，中断处理完毕后，若是可剥夺内核，则检查是否需要进行进程调度，否则直接返回到被中断的内核空间；若需要进行进程调度，则svc_preempt，进程切换。如果当前处于用户空间时，对于 ARM 系统来说是处于USR 模式，此时产生中断，中断处理完毕后，无论是否是可剥夺内核，都调转到统一的用户模式出口ret_to_user，其检查是否需要进行进程调度，若需要进行进程调度，则进程切换，否则直接返回到被中断的用户空间。
三、异常处理方式
Ⅰ、WINDOWS系统的异常处理方式
目前Windows 平台下实现和使用的异常处理机制主要有4 种：筛选器异常处理，结构化异常处理(Structure Exception Handler, SEH)，向量化异常处理(Vectored Exception Handler,VEH)，C++异常处理(C++ Exception Handler, C++EH)。前3 种是由Windows 操作系统实现的异常处理机制，C++EH 是由C++编译器实现的异常处理机制，但它们在其内部实现机理和调用底层函数方面是十分相似的。
1、筛选器异常处理
筛选器异常处理方式，它采用的是在进程范围内注册一个异常处理回调函数，并返回前一个注册的异常处理回调函数的句柄。注册函数如下：
LPTOP_LEVEL_EXCEPTION_FILTER SetUnhandledExceptionFilter( LPTOP_LEVEL_EXCEPTION_FILTER lpTopLevelExceptionFilter
);
其中的参数表示回调函数的地址。
当结构化异常SEH无法处理的时候，系统就会调用筛选器异常处理。当筛选器异常处理也无法搞定的时候，系统会调用系统默认的异常处理程序。筛选器异常处理是属于整个进程的，即是“全局”的，这一点跟SEH不同。
2、结构化异常处理(SEH)
下面是出自《Window核心编程》中一小段内容的引用：“微软在Windows中引入SEH的主要动机是为了便于操作系统本身的开发。操作系统的开发人员使用SEH，使得系统更加强壮。我们也可以使用SEH，使我们的自己的程序更加强壮。使用SEH所造成的负担主要由编译程序来承担，而不是由操作系统承担。当异常块（exception block）出现时，编译程序要生成特殊的代码。编译程序必须产生一些表（table）来支持处理SEH的数据结构。编译程序还必须提供回调（callback）函数，操作系统可以调用这些函数，保证异常块被处理。编译程序还要负责准备栈结构和其他内部信息，供操作系统使用和参考。在编译程序中增加SEH支持不是一件容易的事。不同的编译程序厂商会以不同的方式实现SEH，这一点并不让人感到奇怪。”
可见，SEH 是Windows 平台下使用最早和最广泛的异常处理机制。它最基本的特点是在堆栈中实现并且分为进程相关和线程相关种类型。下面分别对用户模式下的原始型SEH和封装型SEH 进行讨论。
①、原始型SEH
SEH 的进程相关类型是整个进程作用范围的异常处理函数，通过WIN32的API 函数SetUnhandledExceptionFilter进行注册，而操作系统内部使用一个全局变量来记录这个顶层的处理函数，因此只能有一个全局性的异常处理函数。而线程相关类型的作用范围是本线程内，并且可注册多个，甚至可以嵌套注册。两者相比，线程相关类型在实际应用中使用较为广泛。
当线程初始化时，会自动向栈中安装一个异常处理结构，作为线程默认的异常处理。SEH 最基本的数据结构是保存在堆栈中的称为
EXCEPTION_REGISTRATION 的结构体，结构体包括2个元素：第1个元素是指向下一个EXCEPTION_REGISTRATION 结构的指针(prev)，第2个元素是指向异常处理程序的指针(handler)。这样一来，基于堆栈的异常处理程序就相互连接成一个链表。异常处理结构在堆栈中的典型分布如图所示。最顶端的异常处理结构通过线程控制块(TEB)0 Byte 偏移处指针标识，即FS：[0]处地址。
用于进行实际异常处理的函数原型可表示如下：
EXCEPTION_DISPOSITION __cdecl _except_handler(
struct _EXCEPTION_RECORD *ExceptionRecord,
void * EstablisherFrame,
struct _CONTEXT *ContextRecord,
void * DispatcherContext)
该函数的最重要的2个参数是指向_EXCEPTION_RECORD 结构的ExceptionRecord 参数和指向_CONTEXT 结构的ContextRecord 参数，前者主要包括异常类别编码、异常发生地址等重要信息；后者主要包括异常发生时的通用寄存器、调试寄存器和指令寄存器的值等重要的线程执行环境。而用于注册异常处理函数的典型汇编代码可表示如下：
PUSH handler ;
PUSH FS:[0] ;
MOV FS:[0],ESP ;
当异常发生时，操作系统的异常分发函数在进行初始处理后，如果异常没有被处理就会开始在上图所示的线程堆栈上遍历异常处理链，直到异常被处理，如果仍没有注册函数处理异常，则将异常交给缺省处理函数或直接结束产生异常的进程。
②、封装型SEH
通过使用_try{}/_except(){}/_finally{}等关键字，使开发人员更方便地在软件中使用SEH 是封装型SEH 的主要特点。该机制的异常处理数据结构定义如下：
struct VC_EXCEPTION_REGISTRATION
{
VC_EXCEPTION_REGISTRATION* prev;
FARPROC handler;
scopetable_entry* scopetable;
int _index;
DWORD _ebp;
}
其中，结构体中后3 个成员是新增的。而scopetable_entry 的结构如下所示：struct scopetable_entry
{
DWORD prev_entryindex;
FARPROC lpfnFilter;
FARPROC lpfnHandler;
}
封装型SEH 的基本思想是为每个函数内的_try{}块建立一scopetable表，每个_try{}块对应于scopetable中的一项，该项指向_try{}块对应的scopetable_entry 结构，该结构含有与_except(){}/_finally{}对应的过滤函数和处理函数。若有_try{}块嵌套，则在scopetable_entry 结构的prev_entryindex成员中指明，多层嵌套形成单向链表。而每个函数只注册一个VC_EXCEPTION_REGISTRATION 结构，该结构中的handler 成员是一个重要的运行时库函数_except_handler3。该异常处理回调函数负责对结构中的成员进行设置，查找处理函数并根据处理结果决定是继续执行还是让系统继续遍历外层SEH 链。说到底，封装型SHE 的内部机理，它只是扩展了原始型SEH 的功能，使用它可以简化软件开发人员的工作。
3、向量化异常处理(VEH)
向量化异常处理(VEH)是在Windows XP 以后版本中新增的一种异常处理机制。通过使用Win32 API 函数AddVectoredExceptionHandler 就可以注册新的异常处理函数，函数的参数就是指向EXCEPTION_POINTERS 结构的指针。而VEH 用到的数据结构可以构成一个双向链表。通过对用于注册VEH 的函数进行反汇编分析研究可知，VEH 数据结构的相关信息存储在堆中。在用户模式下发生异常时，异常处理分发函数在内部会先调用遍历VEH 记录链表的函数，如果没有找到可以处理异常的注册函数，再开始遍历SEH 注册链表。通过对 VEH 的原理和实现的研究，可以总结出VEH 具有如下的特点：
(1)VEH 是进程相关的，同时可以注册多个，甚至嵌套注册，而且注册的位置可以指定。
(2)VEH 保存在堆中，而不像SEH 保存在堆栈中。
(3)VEH 只能用在用户模式程序中，而SEH 还可以用在内核模式中。
(4)VEH 处理先于SEH 处理执行，只有所有VEH全不处理某个异常的时候，异常处理权才会到达SEH。
正因为 VEH 具有以上特点，所以在实际应用中它的使用更加灵活，甚至可以利用它来实现一个微型调试器。
4、C++异常处理(C++EH)
与SHE, VEH 相比，C++异常处理的内部实现更加复杂，因为它牵扯到类、对象等相关处理，但C++EH 也是建立在基本异常处理机制基础之上的。另外，编译器提供了类似封装型SEH 的关键字try{}/catch(){}/throw 帮助开发人员方便地处理C++程序中出现的各种异常。C++EH 的独有特点有：
首先，C++EH 扩展了EXCEPTION_REGISTRATION 结构，新添加的成员主要作用是当异常发生时用于确定对应的try{}块，功能类似于封装型SEH 结构中的_index 成员。
当编译器对带有C++EH 的函数进行编译时，要添加2 个重的数据结构：一个是异常处理函数_CxxThrowException()；另一个是funcinfo 结构，里面包含对应catch{}块的地址、catch{}块所关心的异常类型等重要的信息。
_CxxThrowException()是C++EH 的统一的异常处理函数，相当于封装型SEH 中的_except_handler3()。_CxxThrowException()函数内部还是调用了Win32API 函数RaiseException()来产生异常，并且异常码是固定的0xE06D7363。
当 C++异常发生时，发生异常函数的funcinfo 结构传给
_CxxThrowException()，开始寻找是否有对该异常感兴趣的catch{}块，如果有就调用catch{}块处理异常；如果没有则沿异常处理链表继续寻找，直到异常被处理或最后抛出错误对话框为止。C++EH 除了增加了funcinfo 结构外，还增加了tryblock, catchblock 等数据结构，主要的目的就是应对复杂的
try{}/catch(){}/throw 结构，在异常发生时能正确找到对应的异常处理块，在发生堆栈展开时能够调用对象的析构函数，释放资源等。
Ⅱ、LINUX系统的异常处理方式
Linux系统把所有进程数据结构都放于内核，这就增加了一些不必要的切换时间。 Linux可以通过系统调用，安装信号的回调函数，这回调函数指针存放在内核的进程数据结构里面。这点Windows处理得比较好，Windows把进程数据结构分成了两部分，一部分敏感数据放于内核的进程数据结构里面，加以保护，另一部分不敏感数据就放于用户空间，这样当访问那些不加保护的数据时，就不用切换到内核，节约了时间。像Windows下异常处理，也是一种回调函数，但因为结构放于用户空间，安装的时候就很方便，也节约切换时间。
除了上述的效率问题，Linux内核并不支持类似Windows下的SHE，当Linux发生异常，会自动产生一个异常中断。在这异常中断处理程序中会判断异常来自用户程序或者内核，如果是发生在用户程序，那么会产生一个异常信号，再根据异常信号的回调函数通知用户程序发生异常。如果发生在内核里面，那么就会搜索内核模块的异常结构表，找到相应的处理调用地址，修改异常中断的返回地址为异常处理的地址，中断返回的时候程序就跳到异常处理程序处理执行。
LInux有个异常模块表，保存会发生异常时候的eip和异常处理程序指针，发
生异常的时候就根据异常时候的eip搜索表里面的eip，发现相等就找到了异常处理指针。这就意味着编写的内核程序必须精确的知道哪条指令可能会发生异常，这样的话要求就会很高。这就不如Windows下的异常编程那么轻松，程序员只需要知道哪一段程序可能出现异常，就只需要一个括号一个异常语句保护这段程序就可以了。
可见异常表对于Linux是多么重要，虽然对于我们的编程来说Linux的异常处理方式较Windows处于下风，但它还是很实用的，下面我们来讨论一下利用异常表处理 Linux 内核态缺页异常的方式。在程序的执行过程中，因为遇到某种障碍而使 CPU 无法最终访问到相应的物理内存单元，即无法完成从虚拟地址到物理地址映射的时候，CPU 会产生一次缺页异常，从而进行相应的缺页异常处理。基于 CPU 的这一特性，Linux 采用了请求调页（Demand Paging）和写时复制（Copy On Write）的技术。
请求调页是一种动态内存分配技术，它把页框的分配推迟到不能再推迟为止。这种技术的动机是：进程开始运行的时候并不访问地址空间中的全部内容。事实上，有一部分地址也许永远也不会被进程所使用。程序的局部性原理也保证了在程序执行的每个阶段，真正使用的进程页只有一小部分，对于临时用不到的页，其所在的页框可以由其它进程使用。因此，请求分页技术增加了系统中的空闲页框的平均数，使内存得到了很好的利用。从另外一个角度来看，在不改变内存大小的情况下，请求分页能够提高系统的吞吐量。当进程要访问的页不在内存中的时候，就通过缺页异常处理将所需页调入内存中。
写时复制主要应用于系统调用fork，父子进程以只读方式共享页框，当其中之一要修改页框时，内核才通过缺页异常处理程序分配一个新的页框，并将页框标记为可写。这种处理方式能够较大的提高系统的性能，这和Linux创建进程的操作过程有一定的关系。在一般情况下，子进程被创建以后会马上通过系统调用execve将一个可执行程序的映象装载进内存中，此时会重新分配子进程的页框。那么，如果fork的时候就对页框进行复制的话，显然是很不合适的。
在上述的两种情况下出现缺页异常，进程运行于用户态，异常处理程序可以让进程从出现异常的指令处恢复执行，使用户感觉不到异常的发生。当然，也会有异常无法正常恢复的情况，这时，异常处理程序会进行一些善后的工作，并结束该进程。也就是说，运行在用户态的进程如果出现缺页异常，不会对操作系统核心的稳定性造成影响。
四、体会
通过以上的对于Windows操作系统和Linux操作系统的中断、异常处理机制的分析，我们了解了他们可以用于不同的场合，并且它们具有各自的优缺点。但我们应该注意的是，我们在使用这些异常处理机制来处理在帮助处理各种异常和错误的同时也是有代价的，它增加了软件在空间和时间上的开销，增加了程序运行在内核模式和用户模式之间的切换次数，因此，应该避免滥用异常处理。同时通过这些分析，我们也可以从中断、异常处理机制的角度看出为什么Windows系统相较于Linux系统对于程序员、普通用户有着较大的吸引力。Windows操作系统的成功可以说源于它自身平台的强大，但是Linux系统是开源的，它是大家的结晶，每一次的技术革新都能使它更加完善，使开发人员的技术可以得到提升。
参考文献：
[1]Jeffrey Richter.Windows核心编程[M].黄拢,李虎,译.北京: 机械工业出版社,2008
[2]罗云彬.Windows环境下32位汇编语言程序设计（第2版）[M].北京：电子工业出版社,2006
[3]Schulman,Andrew.未公开的Windows核心技术[M].全正,等,译.北京:清华大学出版社,1993
[4]潘爱民.Windows内核原理与实现[M].北京:电子工业出版社,2010
[5]吴国伟,李莹,姚琳.Linux内核分析与高级教程[M].北京:清华大学出版
社,2012
[6]邵国金.Linux操作系统[M].北京:电子工业出版社,2012.08
[7]Robert Love.Linux内核设计与实现[M].陈莉君,康华,译.北京:机械工业出版社,2011
计算机体系结构中,异常或者中断是处理系统中突发事件的一种机制，几乎所有的处理器都提供这种机制。异常主要是从处理器被动接受的角度出发的一种描述，指意外操作引起的异常。而中断则带有向处理器主动申请的意味。但这两种情况具有一定的共性，都是请求处理器打断正常的程序执行流程,进入特定程序的一种机制。若无特别说明，对“异常”和“中断”都不作严格的区分。本文结合经过实际验证的代码对ARM９中断处理流程进行分析，并设计出基于S3Ｃ２４1０芯片的外部中断处理程序。 1.异常中断响应和返回 系统运行时，异常可能会随时发生。当一个异常出现以后，ARM微处理器会执行以下几步操作： 1) 将下一条指令的地址存入相应连接寄存器ＬR,以便程序在处理异常返回时能从正确的位置重新开始执行。 2）将ＣPSR复制到相应的SPＳR中。 3）根据异常类型,强制设置CPSR的运行模式位。 4) 强制PC从相关的异常向量地址取下一条指令执行，从而跳转到相应的异常处理程序处。 这些工作是由ＡRM内核完成的,不需要用户程序参与。异常处理完毕之后，ARM微处理器会执行以下几步操作从异常返回： 1）将连接寄存器ＬR的值减去相应的偏移量后送到PC中。 2)将SPSR复制回CPSR中。 3) 若在进入异常处理时设置了中断禁止位,要在此清除。 这些工作必须由用户在中断处理函数中实现。为保证在ARＭ处理器发生异常时不至于处于未知状态，在应用程序的设计中,首先要进行异常处理。采用的方式是在异常向量表中的特定位置放置一条跳转指令,跳转到异常处理程序。当ARＭ处理器发生异常时,程序计数器ＰC会被强制设置为对应的异常向量,从而跳转到异常处理程序。当异常处理完成以后,返回到主程序继续执行。可以认为应用程序总是从复位异常处理程序开始执行的,因此复位异常处理程序不需要返回。 2.异常处理程序设计 2．1 异常响应流程
异常处理是程序设计中一个非常重要的方面，也是程序设计的一大难点，从C开始，你也许已经知道如何用if...else...来控制异常了，也许是自发的，然而这种控制异常痛苦，同一个异常或者错误如果多个地方出现，那么你每个地方都要做相同处理，感觉相当的麻烦！Java 语言在设计的当初就考虑到这些问题，提出异常处理的框架的方案，所有的异常都可以用一个类型来表示，不同类型的异常对应不同的子类异常（这里的异常包括错误概念），定义异常处理的规范，在1.4版本以后增加了异常链机制，从而便于跟踪异常！这是Java语言设计者的高明之处，也是Java语言中的一个难点，下面是我对Java异常知识的一个总结，也算是资源回收一下。 一、Java异常的基础知识 异常是程序中的一些错误，但并不是所有的错误都是异常，并且错误有时候是可以避免的。比如说，你的代码少了一个分号，那么运行出来结果是提示是错误https://www.doczj.com/doc/a35632551.html,ng.Error；如果你用System.out.println(11/0)，那么你是因为你用0做了除数，会抛出https://www.doczj.com/doc/a35632551.html,ng.ArithmeticException的异常。 有些异常需要做处理，有些则不需要捕获处理，后面会详细讲到。 天有不测风云，人有旦夕祸福，Java的程序代码也如此。在编程过程中，首先应当尽可能去避免错误和异常发生，对于不可避免、不可预测的情况则在考虑异常发生时如何处理。Java中的异常用对象来表示。Java对异常的处理是按异常分类处理的，不同异常有不同的分类，每种异常都对应一个类型（class），每个异常都对应一个异常（类的）对象。 异常类从哪里来？有两个来源，一是Java语言本身定义的一些基本异常类型，二是用户通过继承Exception类或者其子类自己定义的异常。Exception 类及其子类是Throwable的一种形式，它指出了合理的应用程序想要捕获的条件。 异常的对象从哪里来呢？有两个来源，一是Java运行时环境自动抛出系统生成的异常，而不管你是否愿意捕获和处理，它总要被抛出！比如除数为0的异常。二是程序员自己抛出的异常，这个异常可以是程序员自己定义的，也可以是Java语言中定义的，用throw 关键字抛出异常，这种异常常用来向调用者汇报异常的一些信息。 异常是针对方法来说的，抛出、声明抛出、捕获和处理异常都是在方法中进行的。 Java异常处理通过5个关键字try、catch、throw、throws、finally进行管理。基本过程是用try语句块包住要监视的语句，如果在try语句块内出现异常，则异常会被抛出，你的代码在catch语句块中可以捕获到这个异常并做处理；还有以部分系统生成的异常在Java运行时自动抛出。你也可以通过throws关键字在方法上声明该方法要抛出异常，然后在方法内部通过throw抛出异常对象。finally语句块会在方法执行return之前执行，一般结构如下： try{ 程序代码 }catch(异常类型1 异常的变量名1){ 程序代码 }catch(异常类型2 异常的变量名2){ 程序代码 }finally{ 程序代码 } catch语句可以有多个，用来匹配多个异常，匹配上多个中一个后，执行catch语句块时候仅仅执行匹配上的异常。catch的类型是Java语言中定义的或者程序员自己定义的，表示代
异常处理流程及注意事项 1.发现不良； （1）确认所采用标准的完整性和有效性； （2）熟练掌握检验所涉及之相关标准或其他文件； （3）严格按抽样标准取样，注意均匀，来料检验须注意来料的不同时间，批号，生产班次等； （4）了解以往的品质状况及其品质履历； （5）掌握品管之检验技巧； 2.标示，区分，隔离； （1）标示，隔离须涉及到具体的不良品和可疑批次，不合格标示要完整且必要时要口头或书面知会先相关人员，以避免他人 混淆误用为原则； （2）不合格标示，隔离须注明不合格原因，检验员，检验日期，进料检验另须注明检验单号，并知会相关人员； 3.初步分析判断，并知会相关单位及现场领导； （1）确定不良等级，异常比率，影响度和影响面，必要时须及时知会相关单位之人员； （2）针对制程或成品类异常，要及时研拟临时对策； （3）进料之异常可能涉及组装或功能之不良，需通过试组装来确定其严重性和影响度，必要时可请工程部帮忙确认； 4.异常提报； （1）异常提报时要注意时效性和准确性，异常单的填写需准确完
整，成品异常要确认追溯批号，PO#与数量； （2）须标示和提供不良品； （3）会签的填写和勾选须正确完整； 5.跟催各相关单位签单状况，根据会签结果处理异常； （1）品管必须跟催会签状况，有迟迟未签之单位必须及时跟催，如多次跟催无效，可请领导协助，以避免异常处理的时效； （2）有签核S物料时，按S物料作业流程处理，并将处理结果维护到异常单中； （3）当物料急上线，且部门领导有同意采用，而高级主管又不在厂内，无法立即签核S单时，可询问品质经理，先输S物料， 以便后续作业； （4）当会签单位处理意见不一致时，需反映部门领导，并确认最终处理结果； 6.确认处理结果； （1）全检或重工后的，需重新确认品质状况，成品类有拆箱之异常，需填写成品不合格处置报表； （2）S物料须对其品质进行跟踪，有异常要及时提报； 7.追踪改善措施； （1）注意改善措施回文必须由责任单位之领导签核，并且要在7个工作日内完成改善措施回文； 8.确认改善结果； （1）评估改善措施之有效性，必要时须修改相关品质系统文件或
异常的基本概念 异常是导致程序终止运行的一种指令流，如果不对异常进行正确的处理，则可能导致程序的中断执行，造成不必要的损失。 在没有异常处理的语言中如果要回避异常，就必须使用大量的判断语句，配合所想到的错误状况来捕捉程序中所有可能发生的错误。 Java异常处理机制具有易于使用、可自行定义异常类、处理抛出的异常同时又不会降低程序运行的速度等优点。因而在java程序设计时应充分地利用java的异常处理机制，以增进程序的稳定性及效率。 当程序中加入了异常处理代码，所以当有异常发生后，整个程序并不会因为异常的产生而中断执行。而是在catch中处理完毕之后，程序正常的结束。 在整个java异常的结构中，实际上有两个最常用的类，分别为Exception和Error 这两个类全都是Throwable的子类。 Exception:一般表示的是程序中出现的问题，可以直接使用try……catch处理。 Error：一般值JVM错误，程序中无法处理。 Java异常处理机制。 在整个java的异常处理中，实际上也是按照面向对象的方式进行处理，处理的步骤如下： 1）一旦产生异常，则首先会产生一个异常类的实例化对象。 2）在try语句中对此异常对象进行捕捉。 3）产生的异常对象与catch语句中的各个异常类型进行匹配，如果匹配成功则执行catch语句中的代码。 异常处理 在定义一个方法时可以使用throws关键字声明，表示此方法不处理异常，而交给方法的调用处进行处理，在方法调用处不管是否有问题，都要使用try……catch块进行异常的捕获与处理。 如果在主方法中使用throws关键字，则程序出现问题后肯定交由jvm处理，将导致程序中断。 与throws关键字不同的是，throw关键字人为的抛出一个异常，抛出时直接抛出异常类的实例化对象即可。 Exception在程序中必须使用try……catch进行处理。RuntimeException可以不使用try……catch进行处理，但是如果有异常产生，则异常将由JVM进行处理。（建议RuntimeException的子类也使用try……catch进行处理，否则产生的异常交给jvm处理会导致程序中断。） 继承关系： Exception》RuntimeException》lllegalArgumentException》NumberFormatException; 异常类必须继承于Exception 建议：继承Exception一般要添加全部父类型一样的构造器！ class NameOrPwdException extends Exception { public NameOrPwdException() {
品质异常处理流程及方法 摘要：品质人员的工作职责之一就是要及时发现反馈生产中的品质异常状况，并督促现场执行改善措施、追踪其改善效果,保证只有合格的产品才能转入下一道工序,生产出高质量的产品. 品质人员的工作职责 1、熟悉所控制范围的工艺流程 2、来料确认 3、按照作业指导书规定进行检验（首检、巡检） 4、作相关的质量记录 5、及时发现反馈生产中的品质异常状况，并督促现场执行改善措施、追踪其改善效果 6、特殊产品的跟踪及质量记录 7、及时提醒现场对各物料及成品明显标识，以免混淆 8、及时纠正作业员的违规操作，督促其按作业指导书作业 9、对转下工序的产品进行质量及标识进行确认 品质异常可能发生的原因 生产现场的品质异常主要指的是在生产过程中发现来料、自制件批量不合格或有批量不合格的趋势。品质异常的原因通常有： A. 来料不合格包括上工序、车间的来料不合格 B. 员工操作不规范，不按作业指导书进行、新员工未经培训或未达到要求就上岗 C. 工装夹具定位不准 D. 设备故障 E. 由于标识不清造成混料 F. 图纸、工艺技术文件错误。 品质异常一般处理流程 1、判断异常的严重程度（要用数据说话） 2、及时反馈品质组长及生产拉长并一起分析异常原因（不良率高时应立即开出停线通知单） 3、查出异常原因后将异常反馈给相关的部门 （1）来料原因反馈上工序改善 （2）人为操作因素反馈生产部改善 （3）机器原因反馈设备部 （4）工艺原因反馈工程部 （5）测量误差反馈计量工程师 （6）原因不明的反馈工程部 4、各相关部门提出改善措施，IPQC督促执行 5、跟踪其改善效果，改善OK，此异常则结案，改善没有效果则继续反馈 怎样做才能尽可能的预防品质异常 SPC是一款专门分析品质异常的工具,它主要是应用统计分析技术对项目过程进行实时监控，区分出过程中
山西煤炭运销集团 蒲县昊锦塬煤业有限公司异常情况处理制度为认真贯彻落实国家、省、市关于集中开展安全生产大检查的工作安排要求，加强我矿信息监控系统管理水平，做好矿井生产过程中井下环境参数的有效监控，保障矿井安全生产，加强煤矿安全生产管理水平及抗灾能力，特制定本矿异常情况处理制度如下： 一、值班人员按《中心岗位责任制》规定，浏览查询煤矿安全信息，发现异常情况及时处理，并认真填写《异常情况报告处理表》，传真至县监控中心。 二、监控室值班人员发现系统发出异常报警后，值班人员必须立即通知监控室主任、分管领导，同时立即通知矿井调度部门，由监控室主任或分管领导组织相关人员对本次异常报警进行原因分析，并按规定程序及时报上一级网络中心。处理结果应记录备案。调度值班人员接到报警、断电信息后，应立即向矿值班领导汇报，矿值班领导按规定指挥现场人员停止工作，断电时撤出人员。处理过程应记录备案。当系统显示井下某一区域瓦斯超限并有可能波及其他区域时，矿井有关人员应按瓦斯事故应急预案手动遥控切断瓦斯可能波及区域的电源。值班人员接到网络中心发出的报警处理指令后，要立即处理落实，并将处理结果向网络中心反馈。 当工作面瓦斯浓度达到报警浓度时，值班人员应立即通知矿值班领导及监控室主任，并填写异常情况处理报告表传真上报至
县监控中心
；由分管领导或监控室主任安排相关人员进行原因分析，按照瓦斯超限分析原则：①按人工检测值与甲烷传感器对比分析； ②按报警地点的历史曲线对比分析；③按报警地点上风侧检测值对比分析。根据分析结果立即将处理措施下达至矿调度中心按处理措施严格执行。报警期间要采取安全措施，报警消除后将报警的起止时间、分析报告、采取措施和处理结果上报县监控室并存档备案。 三、当煤矿通讯中断、无数据显示时，值班人员要通过传真（或电话）向县监控中心报告，并查明原因，恢复通讯。情况紧急的，由值班人员立即向矿领导汇报，对因故造成通讯中断未及时上报的，要通过电话联系移动公司或长途线务局进行抢修。
如何使用异常处理机制 《PHP核心技术与最佳实践》第1章面向对象思想的核心概念，本章将就面向对象一些概念展开讨论，其中重点讨论PHP特色的面向对象的风格和语法，并通过相互借鉴和对比，使读者认识PHP自身的特点，尤其是和其他语言中不同的地方。本节为大家介绍如何使用异常处理机制。 1.6.1 如何使用异常处理机制（1） 异常的思想最早可以追溯到20世纪60年代，其在C++、Java中发扬光大，PHP则部分借鉴了这两种语言的异常处理机制。 PHP里的异常，是程序运行中不符合预期的情况及与正常流程不同的状况。一种不正常的情况，就是按照正常逻辑不该出错，但仍然出错的情况，这属于逻辑和业务流程的一种中断，而不是语法错误。PHP里的错误则属于自身问题，是一种非法语法或者环境问题导致的、让编译器无法通过检查甚至无法运行的情况。 在各种语言里，异常（exception）和错误（error）的概念是不一样的。在PHP里，遇到任何自身错误都会触发一个错误，而不是抛出异常（对于一些情况，会同时抛出异常和错误）。PHP一旦遇到非正常代码，通常都会触发错误，而不是抛出异常。在这个意义上，如果想使用异常处理不可预料的问题，是办不到的。比如，想在文件不存在且数据库连接打不开时触发异常，是不可行的。这在PHP里把它作为错误抛出，而不会作为异常自动捕获。 以经典的除零问题为例，如代码清单1-16所示。 代码清单1-16 exception.php 1.// exception.php 2.getMessage(); 9.$a=-1; 10.}
非惩罚性护理不良事件报告制度及激励机制 一、不良事件的定义 是指在护理过程中发生的、不在计划内的跌倒、坠床、压疮、用药错误、走失、误吸或窒息、烫伤及其他与患者安全相关的非正常的护理意外事件。 二、不良事件报告的意义 通过报告不良事件，及时发现潜在的不安全因素，可有效避免护理差错与纠纷的发生，保障病人安全，不良事件的全面报告，有利于发现医院安全系统存在的不足，提高医院系统安全水平，促进医院及时发现安全事故隐患，不断提高对错误的识别能力，不良事件报告后的信息共存，可以使相关人员从他人的过失中吸取经验教训，以免重蹈覆辙。 三、护理不良事件的范围 1、患者在住院期间发生压疮、坠床、跌倒、导管滑脱、用药失误、走失、误吸或窒息、烫伤及其他与患者安全相关的护理意外。 2、因护理操作失误导致患者出现严重并发症、住院时间延长或住院费用增加等。 3、严重药物不良反应或输血不良反应。 4、严重院内感染。 四、不良事件报告原则 非惩罚性、主动性报告的原则：护理部鼓励护理人员主动、自愿报告不良事件，包括本人的或本科室的，也可报告其他人或其他科室的，可以实名报告，也可匿名报告，对主动报告的科室和个人的有关信息，护理部将严格保密。 五、上报内容 包括患者一般资料，不良事件发生的时间地点、不良事件项目分类、发生的主要原因、采取的措施、患者损害的严重程度及后果和改进措施。上报形式以个人或科室为上报单位。 六、上报形式 1、口头报告：发生严重不良事件时，护理人员应立即向护士长、科主任、总值班、护理部口头报告事件情况。 2、书面报告：护理人员书面填写《护理不良事件报告单》。 3、网络报告：护理人员登录内网，填写《护理不良事件报告单》电子表格，
1.目的 规定当制程出现异常时的处理流程及各相关部门的责任,使异常能够得到及时解决,确保生产正常运行。 2.适用范围 适用于制程出现异常时的处理。 3.定义: 无。 4.职责 4.1各生产车间:当生产过程中制程出现异常时发出《不合格品报告单》通知IPQC 4.2 品质部IPQC:对制程异常现象进行确认,并通知QE或PE来现场进行原因分析与处理 4.3品质部QE:对制程异常进行原因分析并确认责任部门,并对责任部门制订的改善对策进行验证4.4工程部PE:对功能及结构性制程异常进行原因分析并确认责任部门 4.5责任部门:负责制定异常的临时对策与永久对策并实施。 5.作业程序 5.1制程异常发出的时机: 5.1.1 当同一不良现象重复出现且不良率超出备损率时; 5.2 制程异常的发出、确认及通知: 5.2.1由车间生产线根据不良现象与事实填写《不合格品报告单》,填写内容包括:订单号、产品 型号、生产数量、不良数量、不良率、提出部门、提出时间、订单交期、不良现象描述。经车间主管(经理)审核后给车间IPQC确认; 5.2.2 IPQC在收到车间发出的《不合格品单》后,对异常现象、不良数量、不良率进行确认,并将 确认结果填写在“IPQC确认”栏。如果确认结果与车间填写的内容不相符时,可退回车间重新填写。 5.2.3 IPQC确认后以电话形式通知以下人员到发生异常的现场进行原因分析: 5.2.3.1 如果就是外观异常,电话通知制程QE工程师到现场进行原因分析; 5.2.3.2如果就是功能与结构性异常,电话通知QE工程师与工程部PE工程师到现场进行原因 分析; 5.2.3.3如果电话联络不到相关产品的QE工程师或PE工程师时应通知其直接上司做出相应 安排。 5.3原因分析: 5.3.1制程QE工程师与PE工程师接到通知后,应在第一时间到异常发生的车间现场进行确认与 原因分析。 5.3.2问题分析时应运用5WHY、5M1E、8D、QC七大手法、IE手法等问题分析技术分析异常 的根本原因(Root Cause),根据根本原因确认责任部门及提出临时对策。
设备故障 处置过程中的九大错误与解决办法设备故障处理是设备管理和维修人员经常会面对的问题之 O 维修人员在日常的设备故障检查处理过程中，外部受时间、环境、人员等方面的压力，内部受维修人员本身的技术水平、经验、设备熟悉程度、人员身体精神状态等的影响，这些因素，会对故障快速、准确的处置造成一定的影响。 维修人员对设备故障的排查和处置不当，会导致故障处置时间、人力、成本等的增加，或为下次故障留下隐患。 问题一.不能正确判断分析故障,盲目大拆大卸 1、现象： —些维修人员由于对机械结构、原理不清楚，未认真分析清楚故障原因，不能准确判断故障部位，凭着〃大概、差不多〃的思想盲目对机械大拆大卸，结果不但原故障未排除，而且由于维修技能和工艺较差，又出现新的问题。 2、解决办法: 当机械出现故障后，要通过检测设备进行检测，如无检测设备，可通过"问、看、查、试〃等传统的故障判断方法和手段，结合工程机
械的结构和工作原理，确定最可能发生故障的部位。在判定工程机械故障时，一般常用〃排除法〃和〃比较法"，按照从简单到复杂、先外表后内部、先总成再部件的顺序进行，切忌"不问青红皂白，盲目大拆大卸"。 问题二■盲目更换零部件，一味"换件修理" 1、现象： 有些维修人员一贯采用换件试验的方法，不论大件小件，只要认为可能是导致故障的零部件，一个一个更换试验，结果非但故障没排除，且把不该更换的零部件随意更换了，增加了消费者的开支。还有些故障零部件完全可以通过修理恢复其技术性能，不需要复杂修理工艺即可修复，但维修人员却要求用户更换新件，一味采取〃换件修理"的方法，造成严重的浪费。 2、解决办法： 在维修时，应根据故障现象认真分析判断故障原因及部位，对能修复的零部件要采取修理的方法恢复技术性能，杜绝盲目更换零部件的做法。 问题三、不检查新件质量，装配后出现故障 1、现象: 在更换配件前，有些维修人员对新配件不做技术检查，皇来后直接安装到设备上，这种做法是不科学的。目前市场上出售的零配件质量良
异常情况处理流程说明 一、“异常情况”包括 1、质量不合格问题。主要包括制程质量问题、售后质量问题、技术设计或图纸下发后出现问题、调试中 质量问题、外购设备物资质量问题等； 2、交货期延误问题、采购交期延误问题及其他有关生产进度的问题等； 3、生产物料损耗异常问题； 4、生产设备损坏问题； 5、员工违纪问题； 6、其它异常问题。 二、员工出现异常问题，应及时按规定报于部门领导； 三、企管部（质检部）在日常工作中发现员工出现异常问题时，应作出《整改通知》或《整改报告》，由 责任部门签收； 四、员工所属部门部长应及时落实责任人并对问题组织处理。责任人是指直接或间接造成各类问题发生的 员工包括各级管理人员。 五、责任部门部长应督促责任人填写《异常情况处理报告》，责任人应根据问题发生的原因、经过、问题 的现象或后果、问题发生的时间和发现时间，进行详细如实填写，并随后签字确认； 六、责任人填写完毕交直接主管进行原因分析，提出解决措施，并填写《异常情况处理报告》，上交部门 负责人。 1、责任人的直接主管为班长的，该班长应根据问题的具体情况认真分析，确定属于哪种原因，并分析自 己在问题中所负的责任，必须认真填写明白，不得包庇、隐瞒； 2、责任人的直接主管为部长的，则由责任人所属部门部长填写； 3、责任人为部长的，责任人可以不填写此栏，只填写“问题描述”和“责任部门处理意见”； 4、责任人为副总的，责任人填写“问题描述”和“处理意见”； 七、责任人所属部门部长应详细调查、分析问题，确定解决措施，并填写处理报告，依据公司的有关规定 并分析自己在问题中所负的责任，做出公平、公正的处理意见；该部长应本着认真客观的态度对待问题，反思自己工作的欠缺，及时纠正并预防问题的再次发生。 八、责任部门将报告交分管副总，分管副总分析问题发生原因和相关负责人的处理意见，根据公司的有关 规定，对责任人做出处理意见；并由责任部门部长将报告交企管部（质检部）； 九、企管部长（质检部长）实施监督职责，本着公平、公正地原则，对问题深入分析，不确定的问题应重 新调查，并分析责任部门的处理建议是否符合公司的有关规定。若符合规定则填写问题处理报告，做出企管部（质检部）的处理意见；若不符合有关规定，或责任部门的处理意见有失公平、公正，则需
Java异常处理作业 孙月巧 1、参考下面的程序，试修改程序，捕获相关异常，使得程序能正常运行。【提示：用错误数据测试，即可得到异常类名，运行时主方法参数输入abc 测试】 package November; import java.util.Scanner; public class StringIndexOutOf{ public static void main(String args[]){ System.out.println("请输入一个字符串："); try{ Scanner reader=new Scanner(System.in); String str = reader.nextLine(); System.out.println("第四个字符为 " + str.charAt(3)); int aa = Integer.parseInt(str); System.out.println("平方为 " + aa * aa); } catch(StringIndexOutOfBoundsException e){ System.out.println("您输入的数值下标越界"); } catch(NumberFormatException nfe){ System.out.println("您输入的不是数字"); } } } 2、从命令行得到5个整数，放入一整型数组，然后打印输出，要求：如果输入数据不为整数，要捕获Integer.parseInt()产生的异常，显示“请输入整数”，捕获输入参数不足5个的异常(数组越界)，显示“请输入至少5个整数”。 package November; public class Test2 { public static void main(String[] args) { System.out.println("请输入五个整数："); try {
[重点]设备异常处理流程及规定 设备异常处理流程 序流程图责任人表单作业内容号 班组长/线长不能处生产异常出现时，生产部门/设备生产异常理或异常会导致停产时间超过30分钟 1 相关部门/ 时，应立即上报，或开出《生产异常发现者报告单》进行处理。 生产部负责人接到报告后应在10分钟生产部门/内赶赴现场;必要时可同时通知相关相关人员 2 相关部门/ 部门负责人，相关部门负责人接到通赶赴现场负责人知后应在10分钟内赶到现场( 相关部门负责人到达现场后立即对异相关部门异常分析 3 常进行分析，若部门负责人不能到场负责人应在10分钟内派人到达现场( 如不能立即处理应作出是否停产的意确定是总经办/总4 见，并注明预计恢复生产的时间(停否停产经理产应由总经理批准( 相关部门负责人针对问题应在30分钟制定应急相关部门生产异常 5 内制定出应急处理措施，制定措施时处理措施负责人报告单应尽可能地降低影响生产部门生产异常生产部门按应急措施进行生产按照处理6 负责人报告单调整生产措施生产 生产部/品 质部 NG 应急措施的有效性由生产部与品质部生产异常责任人措施7 共同验证，如验证不符合则重新制定报告单验证相关措施( YES 验证结果符合生产及品质相关要求，生产部负责恢复正8 可以在恢复生产后由品质部和生产部人常生产对异常进行跟进确认(
相关责任部生产恢复正常后相关部门应对问题的生产异常 9 制定长期门深层次的原因加以分析，并在两个工报告单预防措施负责人作日内制定出长期预防措施( 生产部生产异常生产部应协同品质部对责任部门的长10 负责人报告单期预防措施执行结果进行跟踪预防措施跟踪 异常处理规定 1(目的 为了更好的规范和完善公司生产异常处理作业，使生产问题发生后，各部门人员迅速、有效的处理，减免停工时间，提高生产效率，特制定本流程。 2(适用范围 适用于公司所有生产异常的处理。 3(职责 3(1 生产部门负责生产异常的反馈和处理措施验证。 3(2 品质部负责品质异常的处理及验证。 3(3 设备组负责设备异常的处理。 3(4 计控部负责物料异常的处理。 3(5 技术部负责技术、关键工序设备、工装模具、工艺异常的处理。 4(作业规范 4.1 生产异常反馈 4.1.1 当生产发生异常或有出现异常的趋势时，生产部发现人员和现场管理人员(如班组长)应即时给予分析，并主动积极寻求解决方法，包括与相关人员联系，如能及时解决则不在本流程规定内。
货物异常应急处置制度 一、目的 确保公司在进行货物运输、装卸、存储等过程中对货物多货、少货、货损、污染、霉变、虫害、火灾、被盗、丢失及其他异常情况进行及时调查分析和处置，并遵守国家相关安全要求。 二、范围 1、本制度适用于货物运输、装卸、存储数量及质量控制； 2、本制度使用货物异常分析及处置。 三、主要职责和权限 1、理货员负责核实出入库货物数量、质量、单据和记录的控制； 2、统计员负责提供货物单据及盘点数量； 3、业务员负责货物异常的追溯、调查及对接客户的处理方案； 4、仓库经理负责处理异常货物。 四、工作程序 1、入库货物多货、少货 （1）货物拆箱时，由理货员依据入库单，清单货物数量。如发现多货或少货，首先与统计员、操作员确认入库单数量是否正确； （2）如确认的确为装箱货物数量异常，则须拍照取证，并及时上报仓库经理、操作员； （3）操作员须及时与客户沟通确认是否继续卸货，待客户确认实际到货数量，并同意卸货后，方可安排叉车工予以卸货； （4）操作员留存客户确认实际到货数量的邮件、微信等截图。 2、出库货物多货、少货 （1）货物装箱时，由理货员依据出库单，查找对应提单号货物存储位置，并检查货物状态，是否有货损、污染、霉变、虫害等情况； （2）如存储期间出现货损、污染、霉变、虫害等情况，则及时报告仓库经理，对异常情况进行调查，必要情况下，须及时通知客户以便出具处理意见； （3）货物检查无异常的，安排并监督叉车工进行装车工作，清点装货数量。 （4）如出库货物到达客户仓库后，被告知货物多货或少货的，则由仓库经理负责调取监控，查看装车视频，清点装车数量，确定为装货时数量异常还是运输过程中数量异常； （5）如装货时少货的，除上报公司外，与客户沟通单独送货还是待下批次货物一同运输； （6）如装货时多货的，除上报公司外，与客户沟通单独退货还是待下批次货物扣除同等数量。 （7）操作员留存客户确认实际到货数量、处理意见的邮件、微信等截图。 3、入库货物货损 （1）货物拆箱时，由理货员依据入库单，检查货物包装。如发现货损情况，则须拍照取证，并及时上报仓库经理、操作员； （2）由仓库经理负责调取监控，查看车辆入场、拆箱视频，确认货损出现原因；
Linux中断处理流程 先从函数注册引出问题吧。 一、中断注册方法 在linux内核中用于申请中断的函数是request_irq（），函数原型在Kernel/irq/manage.c中定义： int request_irq(unsigned int irq, irq_handler_t handler, unsigned long irqflags, const char *devname, void *dev_id) irq是要申请的硬件中断号。 handler是向系统注册的中断处理函数，是一个回调函数，中断发生时，系统调用这个函数，dev_id参数将被传递给它。 irqflags是中断处理的属性，若设置了IRQF_DISABLED （老版本中的SA_INTERRUPT，本版zhon已经不支持了），则表示中断处理程序是快速处理程序，快速处理程序被调用时屏蔽所有中断，慢速处理程 序不屏蔽；若设置了IRQF_SHARED （老版本中的SA_SHIRQ），则表示多个设备共享中断，若设置了IRQF_SAMPLE_RANDOM（老版本中的 SA_SAMPLE_RANDOM），表示对系统熵有贡献，对系统获取随机数有好处。（这几个flag是可以通过或的方式同时使用的） dev_id在中断共享时会用到，一般设置为这个设备的设备结构体或者NULL。devname设置中断名称，在cat /proc/interrupts中可以看到此名称。 request_irq()返回0表示成功，返回-INVAL表示中断号无效或处理函数指针为NULL，返回-EBUSY表示中断已经被占用且不能共享。 关于中断注册的例子，大家可在内核中搜索下request_irq。 在编写驱动的过程中，比较容易产生疑惑的地方是： 1、中断向量表在什么位置？是如何建立的？ 2、从中断开始，系统是怎样执行到我自己注册的函数的？ 3、中断号是如何确定的？对于硬件上有子中断的中断号如何确定？ 4、中断共享是怎么回事，dev_id的作用是？ 本文以2.6.26内核和S3C2410处理器为例，为大家讲解这几个问题。 二、异常向量表的建立 在ARM V4及V4T以后的大部分处理器中，中断向量表的位置可以有两个位置：一个是0，另一个是0xffff0000。可以通过CP15协处理器c1寄存器中V位(bit[13])控制。V和中断向量表的对应关系如下： V=0 ～ 0x00000000~0x0000001C V=1 ～ 0xffff0000~0xffff001C arch/arm/mm/proc-arm920.S中 .section ".text.init", #alloc, #execinstr __arm920_setup: ...... orr r0, r0, #0x2100 @ ..1. ...1 ..11 (1) //bit13=1 中断向量表基址为0xFFFF0000。R0的值将被付给CP15的C1.
1. 异常机制 异常机制是指当程序出现错误后，程序如何处理。具体来说，异常机制提供了程序退出的安全通道。当出现错误后，程序执行的流程发生改变，程序的控制权转移到异常处理器。 传统的处理异常的办法是，函数返回一个特殊的结果来表示出现异常（通常这个特殊结果是大家约定俗称的），调用该函数的程序负责检查并分析函数返回的结果。这样做有如下的弊端：例如函数返回-1代表出现异常，但是如果函数确实要返回-1这个正确的值时就会出现混淆；可读性降低，将程序代码与处理异常的代码混爹在一起；由调用函数的程序来分析错误，这就要求客户程序员对库函数有很深的了解。 异常处理的流程： ①遇到错误，方法立即结束，并不返回一个值；同时，抛出一个异常对象。 ②调用该方法的程序也不会继续执行下去，而是搜索一个可以处理该异常的异常处理器，并执行其中的代码。 2 异常的分类 异常的分类： ①异常的继承结构：基类为Throwable，Error和Exception继承Throwable，RuntimeException和IOException等继承Exception，具体的RuntimeException继承RuntimeException。 ② Error和RuntimeException及其子类成为未检查异常（unchecked），其它异常成为已检查异常（checked）。 每个类型的异常的特点 Error体系： Error类体系描述了Java运行系统中的内部错误以及资源耗尽的情形。应用程序不应该抛出这种类型的对象（一般是由虚拟机抛出）。如果出现这种错误，除了尽力使程序安全退出外，在其他方面是无能为力的。所以，在进行程序设计时，应该更关注Exception体系。 Exception体系包括RuntimeException体系和其他非RuntimeException的体系： ① RuntimeException：RuntimeException体系包括错误的类型转换、数组越界访问和试图访问空指针等等。处理RuntimeException的原则是：如果出现
Windows异常处理流程 作者：SoBeIt 出处：https://www.doczj.com/doc/a35632551.html,/articles/200412/761.html 日期：2005-01-06 先来说说异常和中断的区别。中断可在任何时候发生，与CPU正在执行什么指令无关，中断主要由I/O设备、处理器时钟或定时器等硬件引发，可以被允许或取消。而异常是由于CPU执行了某些指令引起的，可以包括存储器存取违规、除0或者特定调试指令等，内核也将系统服务视为异常。中断和异常更底层的区别是当广义上的中断(包括异常和硬件中断)发生时如果没有设置在服务寄存器(用命令号0xb向8259-1中断控制器0x20端口读出在服务寄存器1，用0xb向8259-2中断控制器的0xa0端口读出在服务寄存器2)相关的在服务位(每个在服务寄存器有8位，共对应IRQ 0-15)则为CPU的异常，否则为硬件中断。 下面是WINDOWS2000根据INTEL x86处理器的定义，将IDT中的前几项注册为对应的异常处理程序(不同的操作系统对此的实现标准是不一样的，这里给出的和其它一些资料不一样是因为这是windows的具体实现)： 中断号名字原因 0x0 除法错误1、DIV和IDIV指令除0 2、除法结果溢出 0x1 调试陷阱1、EFLAG的TF位置位 2、执行到调试寄存器(DR0-DR4)设置的断点 3、执行INT 1指令 0x2 NMI中断将CPU的NMI输入引脚置位(该异常为硬件发生非屏蔽中断而保留) 0x3 断点执行INT 3指令 0x4 整数溢出执行INTO指令且OF位置位 0x5 BOUND边界检查错误BOUND指令比较的值在给定范围外 0x6 无效操作码指令无法识别 0x7 协处理器不可用1、CR0的EM位置位时执行任何协处理器指令 2、协处理器工作时执行了环境切换 0x8 双重异常处理异常时发生另一个异常 0x9 协处理器段超限浮点指令引用内存超过段尾 0xA 无效任务段任务段包含的描述符无效(windows不 使用TSS进行环境切换，所以发生该异常说明有其它问题) 0xB 段不存在被引用的段被换出内存 0xC 堆栈错误1、被引用内存超出堆栈段限制 2、加载入SS寄存器的描述符的present位置0 0xD 一般保护性错误所有其它异常处理例程无法处理的异常 0xE 页面错误1、访问的地址未被换入内存 2、访问操作违反页保护规则 0x10 协处理器出错CR0的EM位置位时执行W AIT或ESCape指令 0x11 对齐检查错误对齐检查开启时(EFLAG对齐位置位)访问未对齐数据
广东樱雪有限公司文件组装车间异常工时责任追究考核管理办法（修订版）为了确保制造部月度产量目标达成，确保公司生产经营紧张有序，生产压力在各生产支持主责模块间有效传递与分解，实现不停线、不断线、不下线，及时暴露生产异常并进行有效责任追究，经公司研究决定特制定本考核管理办法。一、总装车间生产支持主责模块及必须有效支持的项目
二、主要生产异常类型与主责模块责任界定
三、各类生产异常情况责任人分解 四、生产异常情况异常工时责任追究执行标准
五、生产异常责任追究运作模式 1、组装车间在生产过程中出现异常情况时由生产线线长、物料调度（指仓管 的方式通知主责模块第一责任 人，相关责任人收到异常信息后应立即（要求在接到信息的 现场进行处理和确认，如果不到现场处理和确认则视同默认车间反馈的异常事件及处理异常对车间生产影响的时间； 2、的形式通知主责模块第一责任 人（责任人到达现场除外），同时将异常工时与责任模块第一负责人进行口头初步确认； 3、的异常情况，由生产线线长（指发泡总装线）、物料 调度（指仓管员）在填写《异常工时责任追究反馈表》在上交车间主任审核，车间主任审核完后在各生产部部长审批； 4、《异常工时责任追究反馈表》审批流程：生产线线长、仓管员（填写）→ 车间主任（审核）→各生产部部长（审批）； 5、各生产部部长将审批完后的《异常工时责任追究反馈表》在 的形式发送至相关责任人处进行公示； 6、相关责任人在收到《异常工时责任追究反馈表》后默认视同接受，如果有
各生产部部长进行沟通反馈，各生产部部长收到异议反馈后组织异议调查最终将以事实依据作为最终裁定； 7、最终裁定的《异常工时责任追究反馈表》将在事件发生日的 8、生产副总助理汇总上月所有异常工时责任追究统计表输出《异 常工时责任追究月度处罚明细表》，经制生产副总（审核）、总经理（审批）后报送行政部（执行扣罚）； 9、异常工时责任追究月度处罚金额在责任人当月工资中扣除； 10、各班组负责人根据本班组异常工时产生的罚款额度以 形式提交申请，经各制造部部长（一审）、生产副总（二审），生产副总（批准）后报送各生产部车间统计员将罚款额度纳入受影响班组的当月工资总额； 六、其他事项 1、本考核管理办法由生产部负责起草、修订、解释、执行； 2、本考核管理办法从2013年*月*日起试行考核； 3、为了提高各主责模块对异常工时改进的重视程度，要求各主责模块每月收 到正式版《异常工时责任追究月度处罚明细表》后的三个工作日向生产部提交《异常工时改进方案》； 4、各主责模块提交的《异常工时改进方案》，要求要对产生的异常工时进行数 据分析、原因总结、明确改进措施、落实责任人与改善进度； 5、生产部对各部门的《异常工时改进方案》进行收集、审核、评价； 6、行政部对各主责模块《异常工时改进方案》的评价结果纳入部门月度绩效 考核，根据改进的效果对责任部门实行扣分或加分；
设备异常处理程序 1．目的 为了更好的规范和完善公司生产异常处理作业，使生产问题发生后，各部门人员迅速、有效的处理，减免停工时间，提高生产效率，特制定本流程。 2．适用范围 适用于公司所有生产异常的处理。 3．职责 3．1 生产部门负责生产异常的反馈和处理措施验证。 3．2 品质部负责品质异常的处理及验证。 3．3 设备组负责设备异常的处理。 3．4 计控部负责物料异常的处理。 3．5 技术部负责技术、关键工序设备、工装模具、工艺异常的处理。4．作业规范 4.1 生产异常反馈 4.1.1 当生产发生异常或有出现异常的趋势时，生产部发现人员和现场管理人员（如班组长）应即时给予分析，并主动积极寻求解决方法，包括与相关人员联系，如能及时解决则不在本流程规定内。
4.1.2 如情况严重，班组长不能处理或异常会导致停产时间超过30分钟时，应立即报告车间主管，由车间主管进行解决。若车间主管也不能解决时，则由班组长根据异常现状及时开出《生产异常报告单》，经车间主管确认后，报告生产部经理. 4.1.3 生产部经理接到生产异常报告后 10 分钟内赶到现场，对问题进行分类分析，必要时与相关部门负责人联系，寻求支持或召开生产异常协调会进行解决，若相关部门不能配合时，应及时向总经理报告，由总经理协调各职能部门进行解决。 4.2 生产异常处理 4.2.1 相关部门在接到生产异常信息后 10 分钟内(紧急事件立即处理)赶到生产现场，初步分析。如部门负责人不能到现场应在规定时间内派人到场. 4.2.2 根据异常信息由生产部将《生产异常报告单》交异常处理主要责任人. 4.2.3 要求异常处理主要责任人在接到信息后 30 分钟内制定出应急措施. A 质量异常：由品管部负责主导对异常情况进行分析及处理，必要时组织相关部门专题会议讨论解决。 B 设备异常：设备异常由设备组负责对设备进行检修，如不能在规定时间内完成则需向相关生产单位说明，同时提出停产申请并回复确定修复时