低层事件：指硬件相关的错误，比如，除零、浮点错误、内存违例、中断指令。按照C++的观点，它们不属于C++异常的范畴，应由底层错误处理机制（检查防范或SEH异常）来防范或者包装成C++异常（笔者注：应该是从处理效率的角度考虑的）。具体来说，除零和浮点错误，应以防范为主，为了效率也可以用SEH保护代码段；中断指令属于用户特殊行为，由用户自行处理；内存违例，应该是绝对禁止的，以防范为主，一旦出现，即应该以未捕获的SEH异常的形式，抛给调试报错工具处理，必要时由其进行错误现场转储（笔者注：由于Win32各个平台下，默认调试报错工具常不一致、还受安装的调试软件影响，所以实践中，推荐用自定义的未捕获SEH异常处理函数替换系统标准处理过程，更可靠实现错误现场转储）。

C运行库事件：指abort调用、运行时安全检查(堆栈溢出)、_invalid_parameter错误。同样它们不属于C++异常的范畴，一旦出现，也立即终止程序。VC2005 C运行库将其直接抛给系统级的未捕获SEH异常处理函数来处理。(笔者注：可用_set_abort_behavior(0, _WRITE_ABORT_MSG | _CALL_REPORTFAULT), signal(SIGABRT, ...), _set_invalid_parameter_handler，来截获处理。而堆栈溢出，则需要截获UnhandledExceptionFilter来实现)。

标准C++库事件：new、terminate、unexpected调用。这些事件默认以SEH未捕获异常的方式处理。

SEH异常：SEH异常包括了上述的底层事件。SEH异常机制不释放局部对象，因此只推荐用于对底层异常机制的包装。

C++异常：按照C++异常被看成了一种错误处理机制，因此，它并不把底层事件看作异常，而只把throw视为异常，即C++异常机制只直接捕获软件异常，硬件异常需要间接捕获。理解这一点，将有助于我们真正理解C++异常是一种软件手段，而不是保护程序的万能灵药。C++异常会自动释放局部对象，这使得C++异常真正具有了资源安全性，当然前提是，使用局部对象自动释放的机制来保护资源分配。C++异常是应用层开发中错误处理的重要工具，这一点显然还未得到足够的重视，当然这是由于设计、使用C++异常都需要全新的思维观和设计技巧。

附：同步异常与异步异常
1) VC的C++ Exception 采用两种模式捕获异常：同步模式和异步模式。VC的工程的调试版本缺省使用异步模式，工程的发布版本缺省使用同步模式。在同步模式下，VC的编译器假定代码中只有在显示使用throw和调用函数的时候才会引发异常，因此，在同步模式下，VC编译出的代码比较小，但在这种模式下，try-catch对不能捕获内存访问异常与算术除零异常等。在异步模式下，VC的编译器为try块内的每一条语句生成异常捕获代码，在这种情况下，他能够捕获全部的异常，还能保证栈上对象在解栈中正确释放。为了要在发行版本中也能够捕获全部异常就需要打开异步模式，但代价是程序编译出代码变大，运行速度变慢。
2)编译选项：
同步模式的编译选项为/EHs或者/GX(等同于/EHsc)
异步模式的编译选项为/EHa

    软件运行日志是给谁看的？我认为是软件维护人员、资深客户（比如客户方的系统管理员）。软件中的错误信息，应该分为两类，一类是软件用户能够理解的，另一类是软件用户不能理解的，需要软件维护人员介入的。前者，通常与软件用户的操作行为相关，软件用户在得到提示后，可以自行进行处理；而后者，通常与软件自身缺陷、软件部署环境问题相关的，只有软件维护人员才能处理的。很明显，对于后者的详细内容，没必要用告警对话框的方式提供给软件用户，而且这样做，会大大增加软件错误处理的复杂度。直接将其写入运行日志，是最简便、也最可靠的方法。可以想象下面的场景，应用软件在某台电脑上运行出错，软件维护人员或客户方系统管理员查看运行日志，发现了一些系统模块调用失败的信息，并与开发人员远程沟通，开发人员根据这些信息，迅速定位报告错误的代码，随后开发人员可能反馈，某个系统组件没有的到正确的配置，也可能反馈，软件中有一处缺陷，将在下一个版本或补丁包中得到修正。不管是哪一种情况，这一过程让我们感到的是效率和愉悦。

    在了解到软件日志是给谁看的之后，我们就可以合理制定软件中的错误处理策略。一些错误，我们需要逐层向上报，最终得到妥善处理或者向用户给出提示；另一些错误，我们直接将其信息写入软件运行日志，并向上反馈本函数发生了错误，未能成功执行。

    软件运行日志的内容有哪些？我认为可以分为：关键信息提示、警告提示、错误提示、致命问题提示、调试日志。关键信息提示，是指软件执行到了某些重要的节点，就将相应的信息写入软件运行日志，通过这些关键信息提示，我们可以了解软件的大致运行过程是否正常，而它成本非常低廉，相比安装庞大的开发调试环境。警告提示和错误提示，都是用于提示软件中的错误，那么两者之间的区别如何界定呢？还有，调试日志也是报告软件错误的，与这两者又如何相区别呢？

    我认为，调试日志与警告提示、错误提示的本质性区别在于，调试日志是面向开发人员的，是从软件执行的角度发出的；警告提示、错误提示是从软件功能的角度发出的。换而言之，调试日志是记录软件运行中的非正常现象，而警告提示、错误提示是记录软件某项功能失常的相关信息。

    我认为，警告提示、错误提示的本质性区别在于，警告提示是软件功能出现问题，但没有彻底失效；错误提示，就是此项功能完全失效，该项功能停止执行，立即返回；致命问题提示，则是软件整体安全受到威胁。反映到程序中，通常就是，在一个函数中检测到错误后，该函数以失败的方式返回，就报告错误提示；若函数仍能继续执行，就报告告警提示；若该错误严重违例，比如断言违例、内存溢出、堆栈溢出等威胁稳定性的错误，就报告致命问题提示。

    一般来说，致命性提示，通常是与软件自身缺陷引起的，应当引起开发人员的重视；警告提示、错误提示多半是软件运行环境配置问题引起的，但也不排除软件缺陷、用户操作等因素，应当引起软件维护人员、系统管理员的注意。

    对于软件维护人员，调试日志意义不大，而其数据输出量却往往相当大，因此，在软件部署运行环境下，通常应当通过配置开关，关闭调试日志输出。只有开发人员介入后，才有必要打开该开关，从而在缺乏调试工具的环境中，获得丰富的调试信息。

    总的来说，将每一种错误、每一种软件环境配置问题都以对话框的方式提示出来，或许可以减小维护成本，代价却是开发成本成几何级数增长；软件开发中省掉错误处理，的确可减少一些成本，代价是即便一个环境配置问题，都需要开发人员现场调试，软件维护成本大大增加。而软件运行日志，无疑是两者之间取得平衡的关键性武器。

KISS - Keep It Simple Stupid

DRY - Don't Repeat Yourself

在这两句面前，我再写下任何东西都是多余的。

剩下的就是牢记和实践!

（此文是阅读下文的笔记。http://blog.csdn.net/pongba/archive/2009/03/09/3974110.aspx）

Make it work, make it right, make it effective.
DOTDIW原则(Do One Thing,Do It Well).

摘自http://www.cppblog.com/converse/