1、异常影响效率，应该尽量避免？
确实，经充分优化的无异常程序，正常情况下应该会比使用异常处理的程序更为高效，但是随着编译器和虚拟机技术的发展，这种差距越来越小。特别是对于比较复杂的应用系统，反而会出现使用异常的程序更为高效的情况。因为可以把“异常情况”统一进行管理，避免了为每一次的错误都进行设定和约束。真正值得我们在无异常状态下编程的，是底层的系统开发和嵌入式系统，在可以预见的未来，它们仍然是各种编译技巧和微观技术争霸的舞台。这也是为什么C++标准中允许开发者设定编译器是否打开异常支持的原因。
2、在所有的操作步骤中都加入异常处理。
这是另一个极端。经验告诉我们，极端往往是错误的。这一次没有例外。滥用异常，确实会严重影响程序效率。而且异常处理的流程走向，与“正常”的程序流程不同，所以过度使用异常，会导致程序混乱。遇到一段过度使用异常的程序，可能会使阅读者感觉回到了“goto”横行的时代。对于高级语言，编译器会为我们处理语言内部使用的资源。异常通常只在出现错误（系统的或业务规则上的）的时候才被抛出，在调用了外部的资源时才进行保护。这里的“外部资源”，是指编译系统不能自动管理的资源，在不同的语言中，可能会有不同的含义。如在C#和Java语言中，由于虚拟机的存在，我们可以不考虑指针的申请和释放，只对I/O 和数据库联接这样的资源进行保护。但是在ISOC++中，我们就要顾及一旦发生异常，之前申请的指针，以及它们所引用的对象如何得到释放。具体的规则，我们会在后面进行讨论。
3、在什么时机抛出异常？
除了硬件错误，和系统故障引发的底层异常（如资源不足、I/O访问不正常中断、零除等等），支持异常的高级语言还会支持自定义异常。这是一个很有用的功能。这样我们可以把应用系统的错误也并入异常。当然，自定义异常应该有度，通常我们会把有可能危及应用系统运行的错误定义为异常，如文本编码错误，潜在的攻击行为，SOAP接口传递进来的数据格式有误，嵌入脚本的语法错误（如SQL脚本错误，这个通常由Framework统一抛出）等等。但是用户输入错误这样的问题，通常我们不当作异常处理，而是视为系统与用户交互的一部分。
4、异常是否可以代替以前的一些编程技术？
是的，比如我们在Windows API中常见的 ErrorCode Fun（arg1， arg2， ... out arg）；的形式，在新编写的程序中可以不再出现了。我们不必要为了把返回值的位置让给错误码（它未必真的会用得到），而把真正的返回值放到一个引用参数里。现在可以让各个参数各就其位，有错误时，在函数体里throw一个异常对象就可以。它不会占用正常的业务流程，也不再需要我们查询手册来了解错误码代表的意义，异常对象中可以携带任何我们需要的信息。当然，面对新的情况，我们要有新的举措，对于有可能抛出的异常，我们要适时予以截获和处理。
5、何时截获异常？
通常，我们应该在任何调用了外部资源的地方进行异常保护，以确保申请的资源得以正常回收（见第2条），另外在需要原子性保护的事务流中，也要注意异常。截获异常后，不应该简单的屏蔽它，而是针对不同的异常进行适当的处理。与当前流程无关的异常，应该重新向上一级抛出。最后，在应用系统（程序）的主线程中，应该加入一个统一的异常捕获和处理系统，通常应当把未经处理的异常全部记录下来。这个保护代码在一些Framework里已经为我们实现了，我们所要作的只是把我们的异常处理代码写进主线程的错误处理句柄。
针对资源的保护，有几个常见的示例如下：
例如，我们要打开一个文件时，通常在Python中应该这样：
| try: f = open("filename") #加入处理代码。 exceptIOError: #加入IO错误处理 pass finally: f.close() |
而在C#中是
| try { using(FileStream FS = System.IO.File.Open("filename", System.IO.FileMode.Open)) { //添加业务代码 } } catch(ArgumentException) { //添加参数异常处理 } catch(IOException) { //添加IO异常处理 } catch(Exception) { //添加其它异常的处理 } |
