windows异常处理机制
Windows异常处理机制
在windows操作系统下，异常处理机制与调试机制息息相关。理解异常处理机制对于
程序的调试有很大帮助。下文将尝试从异常的产生，异常的分发，异常的处理几个角度进行
探讨，辅以多种异常处理的示例代码进行分析，以期学习更加灵活的调试技巧。
异常的产生
异常和中断非常相似但又有区别。中断可在任何时候发生，与CPU正在执行什么指令
无关，中断主要由I/O设备、处理器时钟或定时器等硬件引发，可以被允许或取消。而异常
是由于CPU执行了某些指令引起的，可以包括存储器存取违规、除0或者特定调试指令等，
内核也将系统服务视为异常。
异常发生时，cpu无法继续运行。此时它将当前线程状态保存，并从中断向量表中根据
异常原因取出对应的异常处理入口，将控制权交给异常处理程序。下表为中断向量表中的异
常原因及对应intel保留的中断号
名字原因
中断
号
0x0 除法错误1、DIV和IDIV指令除0.2、除法结果溢出
0x1 调试陷阱1、EFLAG的TF位置位2、执行到调试寄存器(DR0-DR4)设置的断点3、执行INT1指令
0x2 NMI中断将CPU的NMI输入引脚置位(该异常为硬件发生非屏蔽中断而保留)
0x3 断点执行INT3指令
0x4 整数溢出执行INTO指令且OF位置位
BOUND指令比较的值在给定范围外
0x5 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位置位时执行WAIT或ESCape指令
0x11 对齐检查错误对齐检查开启时(EFLAG对齐位置位)访问未对齐数据
上述异常中，从应用层角度看最为常见的有
1，除零异常，中断号0x0，通常原因为div指令被除数为0
2，调试陷阱，中断号0x1，产生此异常原因通常为单步执行（od的f7，windbg的f11）或硬件断点（windbg的ba指令下的断点产生的异常即为此异常）
3，断点（常称为软断点或cc断点），中断号0x3，此异常用来调试（od的f2，windbg 的bp、bu指令均使用此异常），触发此异常的方法为在应用层直接执行int3指令。
4，页面错误，中断号0xe，产生此异常原因有二。一是访问的线性地址是合法的但页面被换出，在这种情况下，异常处理程序会将磁盘里的内容交换至物理内存，并继续执行。第一种情况对应用层而言是完全透明的。第二种情况为访问违例，如访问一个不存在的线性地址，或违反页保护规则。
异常的分发
异常产生时cpu控制权交给异常处理程序之后，分两种情况。一是os内核可以处理该异常，比如缺页中断，前文已经提到，内核将会直接将磁盘中数据换入物理内存，然后iret 返回异常发生之前的位置，此时线程是完全感觉不到发生了什么。Linux下的fork新任务共享内存写时复制即利用此异常实现。
另一种是内核无法处理该异常。此时如果此异常来自内核，则直接蓝屏。如果此异常来自用户层，根据不同情况将该异常发送给用户层。
上文所谓的不同情况实际上有两种可能，一为进程被调试，二为进程未被调试。被调试进程处理流程如下
流程1
1，检测发生异常的进程是否被调试，发现调试器
2，将异常信息包装为DEBUG_EVENT（调试事件），发送给调试器进程
3，调试器通过WaitForDebugEvent获得该调试事件
4，调试器通过ContinueDebugEvent告知操作系统继续运行，并告知是否已处理该异常5，如果调试器已处理该异常，则被调试线程继续运行，如果未处理，则进入流程2一个典型的调试器调试循环逻辑如下
流程2
1，发生异常进程未被调试，则将异常信息包装为一个Exception Record，连同线程上下文环境Context压至用户态栈。
2，在内核态栈上构造一个陷阱帧（TrapFrame），陷阱帧eip为用户态函数KiUserExceptionDisptcher ，然后iret返回用户态。简言之，相当于调用了一次用户态函数（位于ntdll.dll中）KiUserExceptionDisptcher(ExceptionRecord, ThreadContext).
3，故名思义，KiUserExceptionDispatcher为用户态异常分发器。他的工作流程如下
4，如上图，KiUserExceptionDispatcher将异常记录和线程环境原封不动的发给RtlDispatchException进行实际异常分发。如果返回值非零（处理成功），则调用系统调用ZwContinue返回到异常发生处继续执行。如果返回值为0（处理失败），则调用系统调用ZwRaiseException告知操作系统此进程已无法继续。
5，由4可知，用户态异常分发最核心的函数实际上为RtlDispatchException。该函数比较重要，所以将他的逻辑还原如下（伪代码）
6，如上图，首先遍历veh链表逐个执行异常处理器，一旦某个处理器处理成功，则返回成功，线程继续
7，veh链表遍历完毕，异常仍然没有被处理，则遍历seh链表，逐个检查seh处理器是否合法（safeseh的核心），合法则执行之，一旦某个处理器处理成功，则返回成功，线程继续。注：上图不太准确，seh合法性检验失败之后进程会直接崩溃。
8，veh和seh均未成功处理异常，进程结束。
由RtlDispatchException的分发流程可知，用户层异常首先会发送至veh，其次是seh。下文将逐一介绍
异常的处理
下文按照优先级对异常的各种处理方法简单介绍
Veh---向量异常处理
在win xp及之后操作系统中，微软提供了一个新的异常处理方法，向量异常处理。
在每个进程的动态链接库ntdll中，存在一个向量异常处理器链表，可以向该链表里添加一个节点来注册自己的异常处理器。使用向量异常处理要调用ms提供的一个api，即AddVectoredExceptionHandler ，原型为
WINBASEAPI PVOID WINAPI AddVectoredExceptionHandler(
ULONG FirstHandler,
PVECTORED_EXCEPTION_HANDLER VectoredHandler );
其中FirstHandler非零的话，该处理器会被放到链表头，否则放链表尾。VectoredHandler 为一个函数指针，即为自己定义的异常处理器。类似于linux中的signal，也有同步问题和死循环问题。
VectoredHandler 是进程级的，凡是该进程的所有异常，VectoredHandler 都会被调用。不存在某代码块有效的说法。因此，在VectoredHandler 中访问全局变量要十分谨慎，有同步隐患。同时VectoredHandler 中不能有任何产生异常风险的代码，否则会死循环。
因为vc6不支持veh就不提供示例了。
Seh---结构化异常处理
结构化异常处理可以用__try{}__except(){}关键字来使用,典型的用法如下
实际上__try{}__except(){}的作用就是在栈上构造一个seh节点，并且将该节点放入seh 链表头部。Seh节点的是一个叫_EXCEPTION_REGISTRATION_RECORD 的结构。内容如下：
0:001> dt _EXCEPTION_REGISTRA TION_RECORD
ntdll!_EXCEPTION_REGISTRATION_RECORD
+0x000 Next : Ptr32 _EXCEPTION_REGISTRATION_RECORD
+0x004 Handler : Ptr32 _EXCEPTION_DISPOSITION
看上去就是一个简单的链表。原则上符合上述的结构的节点加入链表之后就能工作。但实际上使用__try{}__except(){}编译器构造出的_EXCEPTION_REGISTRA TION_RECORD 结构要复杂一点，这个和编译器版本相关。
链表的头指针永远放在fs:[0]这个位置，因此seh的安装和卸载通常要操作fs段。
了解了结构，看看如何加入链表的。以上述代码的反汇编为例，加入节点的实现实现如下
其中最关键的四行为
Push offset __except__handler3 /* 在栈上构造结构成员Handler */ Mov eax, large fs:0 /* 取原来的头指针*/
Push eax /* 将原来的头指针作为next放到栈上*/ Mov large fs:0, esp /* 将新构造的结构指针存入fs:0 */
卸载过程则比较简单，改回fs:0即可
下文中不使用__try关键字，直接使用汇编构造seh节点
在这个示例中，首先安装了一个异常处理器handler。然后访问0地址，此时handler被
执行，在handler里修改eax寄存器，让他指向一个合法的位置。返回ExceptionContinueExecution表示此异常已处理，不必继续展开异常处理链。
处理完异常之后，mov eax,[eax]已经可以执行，然后卸载seh节点。
最后再简单介绍一下uef（顶层异常过滤器）。UnhandledExceptionFilter，在一个异常已经确认无法处理进程准备结束的时候，进程还有最后一次机会做善后工作。
使用方法为调用SetUnhandledExceptionFilter添加一个过滤器。实际上uef在也是以链表的形式存在的，当seh链遍历完毕时，seh链尾的系统预设的处理器将遍历uef链。默认的过滤器只是简单的弹出错误框。
最后在总结一下一个异常的生命过程，红线为线程执行顺序
中断异常处理流程
计算机体系结构中,异常或者中断是处理系统中突发事件的一种机制，几乎所有的处理器都提供这种机制。异常主要是从处理器被动接受的角度出发的一种描述，指意外操作引起的异常。而中断则带有向处理器主动申请的意味。但这两种情况具有一定的共性，都是请求处理器打断正常的程序执行流程,进入特定程序的一种机制。若无特别说明，对“异常”和“中断”都不作严格的区分。本文结合经过实际验证的代码对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.wendangku.net/doc/528152772.html,ng.Error；如果你用System.out.println(11/0)，那么你是因为你用0做了除数，会抛出https://www.wendangku.net/doc/528152772.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语言中定义的或者程序员自己定义的，表示代
Windows内存管理机制
Windows内存管理机制 在编程中，很多Windows或C++的内存函数不知道有什么区别，更别谈有效使用；根本的原因是，没有清楚的理解操作系统的内存管理机制，本文企图通过简单的总结描述，结合实例来阐明这个机制。 本文目的： 对Windows内存管理机制了解清楚，有效的利用C++内存函数管理和使用内存。 本文内容： 本文一共有六节，由于篇幅较多，故按节发表。其他章节请看本人博客的Windows内存管理及C++内存分配实例（一）（二）（三）（四）和（五）。 1. 进程地址空间 2.内存状态查询函数 3.内存管理机制--虚拟内存 (VM) 4.内存管理机制--内存映射文件 (Map) 5.内存管理机制--堆 (Heap) 使用场合 操作系统为每个线程都建立一个默认堆栈，大小为1M。这个堆栈是供函数调用时使用，线程内函数里的各种静态变量都是从这个默认堆栈里分配的。
堆栈结构 默认1M的线程堆栈空间的结构举例如下，其中，基地址为0x0004 0000，刚开始时，CPU的堆栈指针寄存器保存的是栈顶的第一个页面地址 0x0013 F000。第二页面为保护页面。这两页是已经分配物理存储器的可用页面。 随着函数的调用，系统将需要更多的页面，假设需要另外5页，则给这5页提交内存，删除原来页面的保护页面属性，最后一页赋予保护页面属性。 当分配倒数第二页0x0004 1000时，系统不再将保护属性赋予它，相反，它会产生堆栈溢出异常STATUS_STACK_OVERFLOW，如果程序没有处理它，则线程将退出。最后一页始终处于保留状态，也就是说可用堆栈数是没有1M的，之所以不用，是防止线程破坏栈底下面的内存（通过违规访问异常达到目的）。
异常处理机制
异常的基本概念 异常是导致程序终止运行的一种指令流，如果不对异常进行正确的处理，则可能导致程序的中断执行，造成不必要的损失。 在没有异常处理的语言中如果要回避异常，就必须使用大量的判断语句，配合所想到的错误状况来捕捉程序中所有可能发生的错误。 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() {
异常情况处理制度及流程
山西煤炭运销集团 蒲县昊锦塬煤业有限公司异常情况处理制度为认真贯彻落实国家、省、市关于集中开展安全生产大检查的工作安排要求，加强我矿信息监控系统管理水平，做好矿井生产过程中井下环境参数的有效监控，保障矿井安全生产，加强煤矿安全生产管理水平及抗灾能力，特制定本矿异常情况处理制度如下： 一、值班人员按《中心岗位责任制》规定，浏览查询煤矿安全信息，发现异常情况及时处理，并认真填写《异常情况报告处理表》，传真至县监控中心。 二、监控室值班人员发现系统发出异常报警后，值班人员必须立即通知监控室主任、分管领导，同时立即通知矿井调度部门，由监控室主任或分管领导组织相关人员对本次异常报警进行原因分析，并按规定程序及时报上一级网络中心。处理结果应记录备案。调度值班人员接到报警、断电信息后，应立即向矿值班领导汇报，矿值班领导按规定指挥现场人员停止工作，断电时撤出人员。处理过程应记录备案。当系统显示井下某一区域瓦斯超限并有可能波及其他区域时，矿井有关人员应按瓦斯事故应急预案手动遥控切断瓦斯可能波及区域的电源。值班人员接到网络中心发出的报警处理指令后，要立即处理落实，并将处理结果向网络中心反馈。 当工作面瓦斯浓度达到报警浓度时，值班人员应立即通知矿值班领导及监控室主任，并填写异常情况处理报告表传真上报至
县监控中心
；由分管领导或监控室主任安排相关人员进行原因分析，按照瓦斯超限分析原则：①按人工检测值与甲烷传感器对比分析； ②按报警地点的历史曲线对比分析；③按报警地点上风侧检测值对比分析。根据分析结果立即将处理措施下达至矿调度中心按处理措施严格执行。报警期间要采取安全措施，报警消除后将报警的起止时间、分析报告、采取措施和处理结果上报县监控室并存档备案。 三、当煤矿通讯中断、无数据显示时，值班人员要通过传真（或电话）向县监控中心报告，并查明原因，恢复通讯。情况紧急的，由值班人员立即向矿领导汇报，对因故造成通讯中断未及时上报的，要通过电话联系移动公司或长途线务局进行抢修。
Windows端口异常占用的处理
Windows端口异常占用的处理 【来源：小鸟云计算】 Ps.小鸟云，国内专业的云计算服务商 问题现象 服务器应用使用的端口被异常占用导致服务启动失败，例如：Windows上安装的Tomcat 无法启动，TCP 80端口已经被其它应用占用。 问题原因 应用程序需要使用的TCP/UDP端口被其它程序、或者病毒木马占用。 排查方法 使用netstat -ano命令可以找出占用端口的进程ID，而后使用tasklist /svc命令找出对应的进程。 如下给出一例安装Tomcat后，启动Tomcat提示端口被占用的处理过程。 1.使用netstat -ano |find ":80" 看到占用端口的进程ID是4，注：请根据实际情况修改端口 2.使用tasklist /svc| find "4" 看到是系统进程。注：请根据实际情况修改进程ID
3.尝试关闭了IIS ，iisreset /stop 4.但是发现80端口仍然被占用。于是使用curl -I 127.0.0.1 查看返回的server是Microsoft-HTTPAPI/2.0 而不是Server: Microsoft-IIS/7.5 能够使用Microsoft-HTTPAPI/2.0的只能是微软的产品。检查是否有安装SQL SERVER ，如果有尝试关闭SQL Server Reporting Service这个服务。 关闭后再使用curl -I 127.0.0.1 就提示80端口无法连接，说明端口已经被释放。 注意：如果没有安装curl还可以使用telnet 127.0.0.1 80 执行完，ctrl+c终止就会出现下面图片的样子，也可以看到server：Microsoft-HTTPAPI/2.0 ，当然仅靠这个是不能判断
如何使用异常处理机制
如何使用异常处理机制 《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、网络报告：护理人员登录内网，填写《护理不良事件报告单》电子表格，
Windows事件驱动机制-1
Windows的事件驱动机制 在Windosw系统中,程序的设计围绕事件驱动来进行。当对象有相关的事件发生时（如按下鼠标键）,对象产生一条特定的标识事件发生的消息,消息被送入消息队列,或不进入队列而直接发送给处理对象,主程序负责组织消息队列,将消息发 送给相应的处理程序,使相应的处理程序执行相应的动作,做完相应的处理后将控制权交还给主程序。 在这种机制中,对象的请求仅仅是向队列中添加相应的消息,耗时的处理则被分离给处理函数。这种结构的程序中各功能模块界限分明,便于扩充,能充分利用CPU 的处理能力,使系统对外界响应准确而及时。 Windows事件驱动机制 我们当中不少使用VC、Delphi等作为开发语言的程序员是一步步从DOS 下的Basic、C++中走过来的，而且大多在刚开始学习编程时也是先从DOS下的编程环境入手的，因此在习惯了DOS下的过程驱动形式的顺序程序设计方法后，往往在向Windows下的开发环境转型的过程中会对Windows所采取的事件驱动方式感到无法适应。因为DOS和Windows这两种操作系统的运行机制是截然不同的，DOS下的任何程序都是使用顺序的、过程驱动的程序设计方法。这种程序都有一个明显的开始、明显的过程以及一个明显的结束，因此通过程序就能直接控制程序事件或过程的全部顺序。即使是在处理异常时，处理过程也仍然是顺序的、过程驱动的结构。而Windows的驱动方式则是事件驱动的，即程序的流程不是由事件的顺序来控制，而是由事件的发生来控制，所有的事件是无序的，所为一个程序员，在编写程序时，并不知道用户会先按下哪个按纽，也就不知道程序先触发哪个消息。因此我们的主要任务就是对正在开发的应用程序要发出的或要接收的消息进行排序和管理。事件驱动程序设计是密切围绕消息的产生与处理而展开的，一条消息是关于发生的事件的消息。 Windows的消息循环 Windows操作系统为每一个正在运行的应用程序保持有一个消息队列。当有事件发生后，Windows并不是将这个激发事件直接送给应用程序，而是先将其翻译成一个Windows消息，然后再把这个消息加入到这个应用程序的消息队列中去。应用程序需要通过消息循环来接收这些消息。在MFC中使用了对WinAPI进行了很好封装的类库，虽然可以为编程提供一个面向对象的界面，使Windows程序员能够以面象对象的方式进行编程，把那些进行SDK编程时最
Windows错误代码解释大全
遇到什么错误了就找找，应该会有帮助的。 6001 0x1771 指定的文件无法解密。 6002 0x1772 指定的文件已加密，而且用户没有能力解密。 6003 0x1773 这个系统没有有效的加密恢复策略配置。 6004 0x1774 所需的加密驱动程序并未加载到系统中。 6005 0x1775 文件加密所使用的加密驱动程序与目前加载的加密驱动程序不同。 6006 0x1776 没有为用户定义EFS 关键字。 6007 0x1777 指定的文件并未加密。 6008 0x1778 指定的文件不是定义的EFS 导出格式。 6009 0x1779 指定的文件是只读文件。 6010 0x177A 已为加密而停用目录。 6011 0x177B 不信任服务器来进行远程加密操作。 6012 0x177C 为此系统配置的恢复策略包含无效恢复证书。 6013 0x177D 用在此源文件上的加密算法需要比目标文件上更大的密钥缓冲区。 6014 0x177E 磁盘分区不支持文件加密。 6015 0x177F 这台机器已为文件加密而停用。 6016 0x1780 需要一个更新的系统来解密此加密文件。 6118 0x17E6 此工作组的服务器列表当前无法使用 6200 0x1838 要正常运行，任务计划程序服务的配置必须在系统帐户中运行。单独的任务可以被配 置成在其他帐户中运行。 6600 0x19C8 日志服务遇到无效日志扇区。 6601 0x19C9 日志服务遇到块校验无效的日志扇区。 6602 0x19CA 日志服务遇到重映射的日志扇区。 6603 0x19CB 日志服务遇到部分或未完成的日志块。 6604 0x19CC 日志服务遇到错误，原因：试图访问活动日志范围外的数据。 6605 0x19CD 日志服务用户排列缓冲区已用尽。 6606 0x19CE 日志服务遇到错误，原因：试图从读取上下文无效的排列区读取。 6607 0x19CF 日志服务遇到无效日志重新启动区域。 6608 0x19D0 日志服务遇到无效日志块版本。 6609 0x19D1 日志服务遇到无效日志块。 6610 0x19D2 日志服务遇到错误，原因：试图以无效读取模式读取。 6611 0x19D3 日志服务遇到错误，原因：日志流没有重启动区。 6612 0x19D4 日志服务遇到损坏的元数据文件。 6613 0x19D5 日志服务遇到无法由日志文件系统创建的元数据文件。 6614 0x19D6 日志服务遇到数据不一致的元数据文件。 6615 0x19D7 日志服务遇到错误，原因：试图分配和排列保留空间。 6616 0x19D8 BITS 报告计划下载已经失败了%2 次。原因是: %1。日志服务无法删除日志文件或 文件系统容器。 6617 0x19D9 日志已经达到允许分配给日志文件的容器的上限。 6618 0x19DA 日志服务试图读取或写入日志开始之前的位置。
Windows错误代码大全
Windows错误代码大全 3001 0x0BB9 指定的打印机驱动程序当前正在使用。 3002 0x0BBA 找不到缓冲文件。 3003 0x0BBB 未发送StartDocPrinter 调用。 3004 0x0BBC 未发送AddJob 调用。 3005 0x0BBD 指定的打印处理器已经安装。 3006 0x0BBE 指定的打印监视器已经安装。 3007 0x0BBF 该指定的打印监视器不具备所要求的功能。 3008 0x0BC0 该指定的打印监视器正在使用中。 3009 0x0BC1 当打印机有作业排队时此操作请求是不允许的。 3010 0x0BC2 请求的操作成功。直到重新启动系统前更改将不会生效。 3011 0x0BC3 请求的操作成功。直到重新启动服务前更改将不会生效。 3012 0x0BC4 找不到打印机。 3013 0x0BC5 已知打印机驱动程序不可靠。 3014 0x0BC6 已知打印机驱动程序会伤害系统。 3020 0x0BCC 在%1 上检测到电源中断。服务器已经暂停。 3021 0x0BCD 在%1 的时候恢复供电。服务器恢复操作。 3022 0x0BCE 因为电池快没电，所以UPS 服务会在%1 关机。 3023 0x0BCF 用户指定的关机命令文件的配置有问题。不过UPS 服务已经启动。 3025 0x0BD1 已经替换驱动器%1 上损坏的扇区(即时修复)。没有丢失数据。您应该尽早运行 CHKDSK，以便完全还原性能，并补充卷的备用扇区池。即时修复是在处理远程请求时进行的。3026 0x0BD2 驱动器%1 的HPFS 卷上发生磁盘错误。错误是在处理远程请求时发生的。 3027 0x0BD3 用户帐户数据库(NET.ACC) 已损坏。本地安全系统正在用在%2 的%1 上备份来替换损坏的NET.ACC。此刻之后对数据库的任何更改会全部丢失。 3028 0x0BD4 找不到用户帐户数据库(NET.ACC)。本地安全系统正在还原%2 的%1 上创建的备用数据库。此刻之后对数据库的任何更改会全部丢失。 3029 0x0BD5 因为用户帐户数据库(NET.ACC) 找不到或损坏，而且也没有可用的备份数据库，
安全生产异常信息报告、收集、分析处理制度(试行)
*********矿井 安全生产异常信息报告、收集、分析处置制度(试行) 第一章总则 第一条为规范矿井安全生产异常信息管理，建立安全生产异常信息报告、收集和分析处置的工作机制，实现安全管理关口前移、超前预警、超前处理，真正做到将事故消灭在萌芽状态，结合矿井现状，特制定本制度。 第二章安全生产异常信息界定 第二条本制度所称的安全生产异常信息，是指事故发生前的异常征兆，必须进行停产撤人。 第三条异常信息内容： 1.地表水无法控制，向井下溃水的； 2.井下发生突水或井下涌水量出现突增等异常情况，危及职工生命及矿井安全的； 3.井下发生瓦斯、煤尘、火灾、水灾等事故危险征兆的； 4.供电系统发生故障，不能保证矿井安全供电的； 5.主要通风机发生故障或通风系统遭到破坏，不能保证矿井正常通风的； 6.监测监控系统出现报警，情况不明的； 7.有害气体指标超限或发现有明火的； 8.井下工作地点瓦斯浓度超过规定的； 9.采掘工作面有冒顶征兆，采取措施不能有效控制的；
10.其他异常情况可能引起停产撤人的。 第三章安全生产异常信息报告、收集、分析处理制度 第四条为有效、果断处置异常信息，超前防范各类事故，成立安全生产异常信息领导小组。 组长：矿长 副组长：安全矿长、技术矿长、生产矿长、机电矿长 成员：各专业副总工程师和专业科室负责负责人 领导小组下设办公室，调度室主任兼任办公室主任，具体负责异常信息报告、收集和分析处理等有关工作。 第五条安全生产异常信息报告 任何人员一旦发现本制度规定的安全生产异常信息，必须及时向调度室报告，调度室值班人员接到安全生产异常信息的报告后，必须立即通知受到安全威胁的人员撤离危险区域，同时通知安全生产异常信息领导小组所有人员到调度室集合。 第六条安全生产异常信息收集 矿井值班、带班领导、区队跟班队长、班组长、安监员、调度员、瓦检员及其他安全管理人员，均为安全生产异常信息收集者，在矿井生产过程中，当发现本制度规定的安全生产异常信息时，必须第一时间发出停产撤人的命令，指挥现场人员撤到安全地点，同时向矿调度室汇报，调度室做好安全生产异常信息的收集记录工作。
货物异常应急处置制度
货物异常应急处置制度 一、目的 确保公司在进行货物运输、装卸、存储等过程中对货物多货、少货、货损、污染、霉变、虫害、火灾、被盗、丢失及其他异常情况进行及时调查分析和处置，并遵守国家相关安全要求。 二、范围 1、本制度适用于货物运输、装卸、存储数量及质量控制； 2、本制度使用货物异常分析及处置。 三、主要职责和权限 1、理货员负责核实出入库货物数量、质量、单据和记录的控制； 2、统计员负责提供货物单据及盘点数量； 3、业务员负责货物异常的追溯、调查及对接客户的处理方案； 4、仓库经理负责处理异常货物。 四、工作程序 1、入库货物多货、少货 （1）货物拆箱时，由理货员依据入库单，清单货物数量。如发现多货或少货，首先与统计员、操作员确认入库单数量是否正确； （2）如确认的确为装箱货物数量异常，则须拍照取证，并及时上报仓库经理、操作员； （3）操作员须及时与客户沟通确认是否继续卸货，待客户确认实际到货数量，并同意卸货后，方可安排叉车工予以卸货； （4）操作员留存客户确认实际到货数量的邮件、微信等截图。 2、出库货物多货、少货 （1）货物装箱时，由理货员依据出库单，查找对应提单号货物存储位置，并检查货物状态，是否有货损、污染、霉变、虫害等情况； （2）如存储期间出现货损、污染、霉变、虫害等情况，则及时报告仓库经理，对异常情况进行调查，必要情况下，须及时通知客户以便出具处理意见； （3）货物检查无异常的，安排并监督叉车工进行装车工作，清点装货数量。 （4）如出库货物到达客户仓库后，被告知货物多货或少货的，则由仓库经理负责调取监控，查看装车视频，清点装车数量，确定为装货时数量异常还是运输过程中数量异常； （5）如装货时少货的，除上报公司外，与客户沟通单独送货还是待下批次货物一同运输； （6）如装货时多货的，除上报公司外，与客户沟通单独退货还是待下批次货物扣除同等数量。 （7）操作员留存客户确认实际到货数量、处理意见的邮件、微信等截图。 3、入库货物货损 （1）货物拆箱时，由理货员依据入库单，检查货物包装。如发现货损情况，则须拍照取证，并及时上报仓库经理、操作员； （2）由仓库经理负责调取监控，查看车辆入场、拆箱视频，确认货损出现原因；
Linux中断处理流程
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代表出现异常，但是如果函数确实要返回-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异常处理流程
Windows异常处理流程 作者：SoBeIt 出处：https://www.wendangku.net/doc/528152772.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、行政部对各主责模块《异常工时改进方案》的评价结果纳入部门月度绩效 考核，根据改进的效果对责任部门实行扣分或加分；
windows异常处理机制
Windows异常处理机制 在windows操作系统下，异常处理机制与调试机制息息相关。理解异常处理机制对于 程序的调试有很大帮助。下文将尝试从异常的产生，异常的分发，异常的处理几个角度进行 探讨，辅以多种异常处理的示例代码进行分析，以期学习更加灵活的调试技巧。 异常的产生 异常和中断非常相似但又有区别。中断可在任何时候发生，与CPU正在执行什么指令 无关，中断主要由I/O设备、处理器时钟或定时器等硬件引发，可以被允许或取消。而异常 是由于CPU执行了某些指令引起的，可以包括存储器存取违规、除0或者特定调试指令等， 内核也将系统服务视为异常。 异常发生时，cpu无法继续运行。此时它将当前线程状态保存，并从中断向量表中根据 异常原因取出对应的异常处理入口，将控制权交给异常处理程序。下表为中断向量表中的异 常原因及对应intel保留的中断号 名字原因 中断 号 0x0 除法错误1、DIV和IDIV指令除0.2、除法结果溢出 0x1 调试陷阱1、EFLAG的TF位置位2、执行到调试寄存器(DR0-DR4)设置的断点3、执行INT1指令 0x2 NMI中断将CPU的NMI输入引脚置位(该异常为硬件发生非屏蔽中断而保留) 0x3 断点执行INT3指令 0x4 整数溢出执行INTO指令且OF位置位 BOUND指令比较的值在给定范围外 0x5 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位置位时执行WAIT或ESCape指令 0x11 对齐检查错误对齐检查开启时(EFLAG对齐位置位)访问未对齐数据
详解异常处理机制
详解异常处理机制 当一个程序出现错误时，它可能的情况有3种：语法错误，运行时错误和逻辑错误。语法错误是指代码的格式错了，或者某个字母输错了;运行时错误是指在程序运行的时候出现的一些么有想到的错误，如：空指针异常，数组越界，除数为零等;逻辑错误是指运行结果与预想的结果不一样，这是一种很难调试的错误。 AD： 当一个程序出现错误时，它可能的情况有3种：语法错误，运行时错误和逻辑错误。语法错误是指代码的格式错了，或者某个字母输错了;运行时错误是指在程序运行的时候出现的一些么有想到的错误，如：空指针异常，数组越界，除数为零等;逻辑错误是指运行结果与预想的结果不一样，这是一种很难调试的错误。而java中的异常处理机制主要是指处理运行时错误，即异常就是运行时错误。 产生异常的原因有3中：1.java内部发生错误，java虚拟机产生的异常。2.编写程序的时候由于错误引起的异常，如：空指针异常，数组越界等。3.通过throw语句生成的异常。这种异常通常称为“检查异常”，用来告知方法的调用着相关信息。 java通过面向对象的方法处理异常。在一个方法的运行过程中如果出现了异常，这个方法就会产生代表该异常的一个对象，把它交给运行时系统，运行时系统寻找相应的代码来处理这一异常。其中，生成异常对象，并把它交个运行时系统的过程称为抛出(throw)。运行时系统在方法的调用栈中查找，直到找到能处理该异常的对象的过程称为捕获(catch)。 一、异常的分类 在java中，任何异常都属于https://www.wendangku.net/doc/528152772.html,ng.Throwable类或其子类，Throwable类又分为Exception类和Error 类。其中Exception类用于用户所出现的各种异常，它也可用来创建自定义类型的类。Error类异常是指java程序运行时与运行是系统本身有关的错误，这些异常通常是灾难性的，不是程序可以控制的。 Exception类的异常又分为运行时异常和非运行时异常。其中运行时异常是指RuntimeException类及其子类，这些异常不检查异常，可以选择捕获处理，也不可以不处理。非运行时错误是除RuntimeException类以外的异常，这些异常必须处理，否则会导致程序编译不能通过。 二、异常处理机制 处理异常的方式主要有两种：积极的处理方式和消极的处理方式。 积极的处理方式主要是使用try...catch，程序先执行try中的语句，当try中的语句出现异常时，就停止当前程序的执行，转入到catch中执行语句，若catch语句中出现异常，程序也会停止执行，然后转到catch的下一个程序继续执行。也就是说try语句用来发现异常，而catch语句用来处理异常。通常在catch 语句后会跟一个final语句，与try...catch语句结合使用，无论try和catch中是否出现异常，final 中的语句都会直线。如果一个方法必须返回一个值的话，那么把return语句放到final中最合适了，因为要是放到try或catch中的任何一个，如果运行过程中出现异常的话，程序就会停止执行，也就无法执行retrun了。