《C++的错误和异常处理分析.docx》由会员分享，可在线阅读，更多相关《C++的错误和异常处理分析.docx（5页珍藏版）》请在金锄头文库上搜索。
1、 C+的错误和异常处理分析struct my_exc1 : std:exception char const* what() const throw(); ;struct my_exc2 : std:exception char const* what() const throw(); ;struct your_exc3 : my_exc1, my_exc2 ; int main() try throw your_exc3(); catch(std:exception const 上面的程序将打印出“whoops” ,由于C+运行时刻无法打算用那个exception实例去匹配第一个catch.
2、(秃子：我的建议是这里别使用多重继承) 3. 不要内嵌std:string对象或者其他拷贝构造可能抛出特别的数据成员、基类。在上述点抛出特别将导致直接调用std:terminate().让基类或数据成员的默认构造函数可能抛出特别也是同样糟糕的办法，你原来是准备通过一个包含对象构造的throw表达式报告特别, 程序却无谓地中止了： throw some_exception(); 当发生特别拷贝时，有几种方法避开复制字符串对象，例如在特别对象中嵌入一个定长存储区，或者通过引用计数来治理字符串。不过，在采纳这些方法前，先考虑考虑下一条。 4. 只在的确需要的时候才格式化what()返回的信息。格式化
3、是一个典型的内存相关的操作，有可能抛出特别。把格式化推迟到栈绽开之后，由于栈绽开可能释放某些资源。对what()函数用catch(.)块加以爱护是一个好办法，这样你就可以在格式化抛出特别时有了一个退路。 5. 不要太在意what()的信息。在特别抛出点，对程序员来说，这是给出错误信息的好时机，但是你未必能够把相关信息组合成用户可以理解的形式。国际化就一个典型的状况。Peter Dimov给出了良好建议：建一个错误信息格式化的表格，把what()的字符串作为这个表的键。当标准库抛出特别时，假如我们只能获得其标准的what()字符串 6. 在特别类的public接口中暴露导致错误的有关信息。返回固
4、定信息的what()意味着你无视了暴露信息，而用户可能需要供应相关信息。例如，你的特别想报告数字范围错，报错的代码应当能够透过特别的公共接口让特别包含导致问题的那个变量值。假如你只是在what()中以文本方式表现这些数字，那些需要依据信息做更多（或更少）处理的程序员日子将很难受。 7. 假如可能，让你的特别类对两次析构免疫。几款流行的编译器间或会使特别对象被销毁两次。假如你能实行措施防备危害（比方，把释放的指针置零）就可以使代码更强健。 如何处理程序员犯错？ 作为开发者，假如我违反了所使用库的某个前条件，我不盼望栈绽开。我盼望的是core dump或者等价物一个能准确地在问题发生点检查程序状态
5、的方法。这通常意味着assert()或者其他类似的东西。 有时候为用户供应可以应付任意误用的强健的API是有必要的，但这样通常要付出不菲的代价。比方，一个常见需求是跟踪客户使用的每一个对象，从而可以验证合法性。假如你需要这种爱护，通常是在一个简洁API上再封装一层来实现。尽管你做得当心翼翼，有强健的API也只能防备某些而不是全部会导致灾难的误用。客户也开头依靠那些爱护并且所依靠的爱护也将增长到接口爱护不到的局部。 Windows开发者请留意：当你使用assert()时，大局部Windows编译器实际上都是抛出特别，并且被本地截获，这很不幸。事实上，截获的错误常常是段访问失败或者除零错。当你使用
6、JIT(Just In Time)调试时这是个问题，这意味着在在唤醒调试器之前已经特别栈绽开了，由于catch()将捕获这个特别，其实这个并非C+特别。幸运的是，有一个鲜为人知的简洁方法可以处理： extern “C“ void straight_to_debugger(unsigned int, EXCEPTION_POINTERS*) throw;extern “C“ void (*old_translator)(unsigned, EXCEPTION_POINTERS*)= _set_se_translator(straight_to_debugger); 这个方法无法应付在catch块
7、中（或者catch块调用的函数中）抛出构造化特别的状况，但它的确可以解决绝大多数JIT导致的问题。 该如何处理特别？ 压根就不处理特别一般是处理特别的方法。假如你让特别穿越你的代码，并且在析构函数中做清理工作，代码会更洁净。 尽可能避开catch() 很不幸，其他非Windows操作系统一样会把非C+特别（例如线程中止）卷入到C+特别机制中去，而且，有时候也没有类似上面提到的_set_se_translator这样的hack手法加以解决。我们通常在析构函数或者catch块中做合理操作来维持系统的不变式，这通常是安全的。然而catch(.)也会捕获非预期的系统通知，这时是不行能像对待一般C+特别一样来处理的，惯用的手法不再安全了。 经过新闻组上长期的辩论之后，尽管不情愿，我还是得成认Hillel Y. Sims观点：除非全部操作系统修正前面的问题，否则，全部特别应当继承自std:exception，当全部人适应catch(std:exception&)而不是catch(.)时，世界将会更加美妙。 即使不考虑和操作系统间糟糕的交互状况，有时候，catch(.)仍旧是最适宜的选择。假如你根本不知道会有什么特别抛出，并且必需停顿栈绽开，这可能是你出路。一个典型的状况就是跨语言的时候。
