并不是每个C++程序都应该使用异常处理，因为抛出异常不像正常函数调用那样快，所以异常处理应该用在独立开发的不同程序部分之间，用于不正常情况的通信。如果程序实现者遇到一种不能局部处理的意外情况，他可能会抛出一个异常来通知调用者。由于对一个异常的认定没有一个固定的标准，对于在栈满时压入一个值的操作来说，可以认为这是个异常而throw出来，也可以认为这是个正常的动作，把栈扩大后再push。异常处理是容错系统实现中的主要辅助手段。决定一个程序是否处理由库抛出的异常，或者是让程序终止运行，是设计过程的一大难点。
运用异常处理的一些最佳方案：
1. 在一个层或组件中，不是每个函数都能够处理异常。try块和catch子句通常被一个程序组件的入口点函数使用。
2. 对不正常的条件使用异常，尽可能准确的使用预定义的异常。使用系统提供的异常能够减少代码，提高代码的可读性（特别是新人不需要了解自定义的异常结构）。大多数情况下，系统提供的异常已经足够用了。
3. 尽可能多的收集异常发生时的上下文信息。异常之所以比返回码优秀的一个原因就是它能够将错误类型化，提供比错误代码多得多的信息。因此，我们实在没理由不使用这一功能。
4. 异常处理是一种昂贵的开销，应该用来处理异常状态而不是用来控制逻辑上的规则。
5. 避免在一个循环中使用异常处理，如果真的需要这样，把try/catch块放在循环外面进行。
6. 对于那些可预知的,能通过编程方式来避免发生的错误来说，尽量使用编程的方式来解决。
7. 在不必要的情况下尽量不要rethrow一个异常，因为rethrow同样有代价的。
8. 始终按从最特定到最不特定的顺序对catch块中的异常排序。此方法在将特定异常传递给更常规的catch块之前处理该异常。
9. 不要从 Exception 基类派生用户定义的异常。对于大多数应用程序，从 ApplicationException 类派生自定义异常。
10. 以“Exception”这个词作为异常类名的结尾。
11. 运用一系列的catch块可以做到用不同的方法处理不同的异常。例如处理文件有关的异常时，需要catch以下异常(FileNotFoundException, DirectoryNotFoundException, SecurityException, IOException, UnauthorizedAccessException, Exception)。
异常在组织中的最大作用是它清晰的定义了类开发者和类调用者之间的契约关系。所以，我们希望类的开发者清楚的说明一个方法在什么条件下会出现什么样的异常，类调用者则需要保证他的调用对异常有明确、完整的处理。为了达到这样的效果需要注意几点：
1.在设计类时，需要同时设计异常类，并编写异常类的说明文档。(对于类的设计者来说，应该在简化其他人调用上下功夫，要么返回正常，要么发生有类型的异常。)
2.在给出类和方法的说明时，需要给出异常的定义和触发的条件。
3.在代码中使用异常，而不是返回值。
4.对输入参数进行判定，使用参数不正确异常和空指针异常。
5.测试一遍所有的异常。
6.方法调用时，如果方法中有异常，必须使用try块进行异常处理。
