我应该在C ++中使用异常说明符吗？

在C ++中，可以通过使用异常说明符来指定一个函数可以抛出异常，也可以不抛出异常。例如：

void foo() throw(); // guaranteed not to throw an exception
void bar() throw(int); // may throw an exception of type int
void baz() throw(...); // may throw an exception of some unspecified type

由于以下原因，我对实际使用它们表示怀疑：

1. 编译器实际上并没有以任何严格的方式强制执行异常说明符，因此好处并不大。理想情况下，您希望获得一个编译错误。
2. 如果函数违反异常说明符，我认为标准行为是终止程序。
3. 在VS.Net中，它将throw（X）视为throw（...），因此对标准的遵循性不强。

您认为应该使用异常说明符吗？
请回答“是”或“否”，并提供一些理由来证明您的回答合理。

没有。

这是为什么的几个示例：

1. 模板代码无法使用异常规范编写，

   template<class T>
   void f( T k )
   {
        T x( k );
        x.x();
   }

   副本可能会抛出，参数传递可能会抛出，并且x()可能会抛出一些未知异常。

2. 异常规范倾向于禁止扩展性。

   virtual void open() throw( FileNotFound );

   可能演变成

   virtual void open() throw( FileNotFound, SocketNotReady, InterprocessObjectNotImplemented, HardwareUnresponsive );

   你真的可以写成

   throw( ... )

   第一个是不可扩展的，第二个是过于雄心勃勃的，第三个实际上是您在编写虚拟函数时的意思。

3. 旧版代码

   当您编写依赖于另一个库的代码时，您真的不知道当出现严重错误时它可能会做什么。

   int lib_f();
   
   void g() throw( k_too_small_exception )
   { 
      int k = lib_f();
      if( k < 0 ) throw k_too_small_exception();
   }

   glib_f()抛出时将终止。（在大多数情况下）这不是您真正想要的。std::terminate()永远不应该被调用。总是让应用程序因未处理的异常而崩溃（从中可以检索堆栈跟踪）总是比静默/剧烈地崩溃更好。

4. 编写返回常见错误并在特殊情况下抛出的代码。

   Error e = open( "bla.txt" );
   if( e == FileNotFound )
       MessageUser( "File bla.txt not found" );
   if( e == AccessDenied )
       MessageUser( "Failed to open bla.txt, because we don't have read rights ..." );
   if( e != Success )
       MessageUser( "Failed due to some other error, error code = " + itoa( e ) );
   
   try
   {
      std::vector<TObj> k( 1000 );
      // ...
   }
   catch( const bad_alloc& b )
   { 
      MessageUser( "out of memory, exiting process" );
      throw;
   }

不过，当您的库仅引发您自己的异常时，您可以使用异常规范说明您的意图。

避免使用C ++中的异常规范。您提出问题的理由是一个很好的起点。

参见Herb Sutter的“对异常规范的实用观察”。

我认为除约定外（对于C ++），标准
例外说明符是在C ++标准中进行的一项实验，多数失败。
唯一的例外是“不抛出”说明符很有用，但您还应该在内部添加适当的try catch块以确保代码与说明符匹配。Herb Sutter在此主题上有一页。戈特82

另外，我认为值得描述例外保证。

这些基本上是关于对象的状态如何受到异常转义的方法的文档。不幸的是，它们没有被编译器强制执行或以其他方式提及。
提升和例外

例外保证

不保证：

在异常转义方法之后，无法保证对象的状态。
在这些情况下，不应再使用该对象。

基本保证：

在几乎所有情况下，这都应该是方法提供的最低保证。
这保证了对象的状态定义正确，并且仍然可以被一致地使用。

强有力的保证：（又名交易保证）

这保证了该方法将成功完成，
否则将引发异常并且对象状态不会更改。

无掷保证：

该方法保证不允许异常传播到该方法之外。
所有破坏者都应作出此保证。
| 注意：如果在已传播异常的情况下异常逃脱了析构函数
| 该应用程序将终止

当您违反异常规范时，gcc将发出警告。我要做的是仅在“ lint”模式下使用宏来使用异常规范，以明确进行检查以确保异常与我的文档一致。

唯一有用的异常说明符是“ throw（）”，如“不抛出”。

异常规范不是C ++中非常有用的工具。但是，如果将它们与std :: unexpected结合使用，则/ is /有很好的用途。

在某些项目中，我要做的是编写具有异常规范的代码，然后使用将抛出我自己设计的特殊异常的函数调用set_unexpected（）。构造后，此异常获取回溯（以特定于平台的方式），并从std :: bad_exception派生（如果需要，可以传播它）。如果它像通常那样引起了一个terate（）调用，则回溯将由what（）打印（以及引起它的原始异常；不难发现），因此我获得了我的合同在哪里的信息。违反，例如引发了意外的库异常。

如果这样做，我将永远不允许传播库异常（std异常除外），并从std :: exception派生我的所有异常。如果库决定抛出，则我将捕获并转换为自己的层次结构，从而使我能够始终控制代码。由于明显的原因，调用依赖函数的模板化函数应避免使用异常规范。但是无论如何，很少有带有库代码的模板化函数接口（很少有库确实以有用的方式使用模板）。

如果您要编写的代码供人们使用，而他们宁愿看一下函数声明而不是周围的任何注释，那么规范将告诉他们他们可能想捕获哪些异常。

否则，我觉得使用任何东西并不是特别有用，只是throw()表明它不会引发任何异常。

否。如果使用它们，并且引发了未指定的异常（无论是通过代码还是由代码调用的代码），则默认行为是立即终止程序。

另外，我相信在C ++ 0x标准的当前草案中已不赞成使用它们。

如果“ throw（）”规范知道函数永远不会抛出异常（或者至少承诺永远不会抛出异常），则允许编译器在进行代码流分析时执行一些优化。拉里·奥斯特曼（Larry Osterman）在这里简短地谈到了这一点：

http://blogs.msdn.com/larryosterman/archive/2006/03/22/558390.aspx

通常，我不会使用异常说明符。但是，如果所讨论的功能会导致其他任何异常导致程序肯定无法更正，则此功能很有用。在所有情况下，请确保清楚地记录该功能可能发生的异常情况。

是的，从带有异常说明符的函数引发的未指定异常的预期行为是调用Terminate（）。

我还将注意到，斯科特·迈耶斯（Scott Meyers）在《更有效的C ++》中解决了这个问题。强烈推荐他的有效C ++和更有效C ++。

是的，如果您需要内部文档。或者也许写一个别人可以使用的库，这样他们就可以知道发生了什么而无需查阅文档。抛出或不抛出都可以视为API的一部分，就像返回值一样。

我同意，它们对于在编译器中强制正确性Java样式并不是真正有用，但是总比没有注释或随意注释好。

它们对于单元测试很有用，因此在编写测试时，您会知道该函数在失败时会抛出什么结果，但是在编译器中不会对其进行强制执行。我认为它们是C ++中不必要的额外代码。您应该确保选择哪种方法，就是在项目和团队成员之间遵循相同的编码标准，从而使代码保持可读性。

从文章：

http://www.boost.org/community/exception_safety.html

“众所周知，编写异常安全的通用容器是不可能的。” 通常会参考Tom Cargill [4]的一篇文章听到这种说法，他在其中探讨了通用堆栈模板的异常安全性问题。嘉吉在他的文章中提出了许多有用的问题，但不幸的是未能提出解决问题的方法。1他最后指出，不可能解决。不幸的是，许多人认为他的文章是这种推测的“证明”。自从它发布以来，已经有很多异常安全通用组件的示例，其中包括C ++标准库容器。

实际上，我可以想到使模板类异常安全的方法。除非您无法控制所有子类，否则您可能仍然会遇到问题。为此，您可以在您的类中创建typedef，以定义各种模板类引发的异常。这种想法是一如既往地将其解决，而不是一开始就进行设计。我认为，这是真正的障碍。

异常规范=垃圾，请问30岁以上的任何Java开发人员