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

发布于 2024-07-05 00:41:07 字数 539 浏览 8 评论 0原文

在 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

我对实际使用它们持怀疑态度，因为以下原因：

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

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

原文

In C++, you can specify that a function may or may not throw an exception by using an exception specifier. For example:

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

I'm doubtful about actually using them because of the following:

The compiler doesn't really enforce exception specifiers in any rigorous way, so the benefits are not great. Ideally, you would like to get a compile error.
If a function violates an exception specifier, I think the standard behaviour is to terminate the program.
In VS.Net, it treats throw(X) as throw(...), so adherence to the standard is not strong.

Do you think exception specifiers should be used?
Please answer with "yes" or "no" and provide some reasons to justify your answer.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

〃温暖了心ぐ 2024-07-12 00:41:08

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

回复收藏 0 原文

无语# 2024-07-12 00:41:08

来自文章：

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

“众所周知，不可能
编写异常安全的泛型
容器。” 这种说法经常听到
参考汤姆的文章
嘉吉 [4] 在其中他探索了
异常安全问题
通用堆栈模板。在他的
文章中，嘉吉提出了许多有用的
问题，但不幸的是未能
提出他的问题的解决方案。1 他
最后建议
解决方案可能无法实现。
不幸的是，他的文章被阅读了
许多人将其视为这种猜测的“证据”。
自发布以来已有
许多异常安全的例子
通用组件，其中包括 C++
标准库容器。

事实上，我可以想出使模板类异常安全的方法。除非您无法控制所有子类，否则您可能会遇到问题。为此，可以在类中创建 typedef，定义各种模板类引发的异常。我认为问题总是事后附加它，而不是从一开始就设计它，我认为这种开销才是真正的障碍。

回复收藏 0 原文

临风闻羌笛 2024-07-12 00:41:08

它们对于单元测试很有用，这样在编写测试时您就知道函数失败时会抛出什么，但编译器中没有强制执行它们。我认为它们是 C++ 中不必要的额外代码。无论您选择哪一个，您都应该确保在整个项目和团队成员中遵循相同的编码标准，以便您的代码保持可读性。

回复收藏 0 原文

禾厶谷欠 2024-07-12 00:41:08

一般来说我不会使用异常说明符。然而，如果任何其他异常来自有问题的函数，程序肯定无法纠正，那么它可能会很有用。在所有情况下，请确保清楚地记录该函数可能出现的异常情况。

是的，从带有异常说明符的函数抛出的非指定异常的预期行为是调用terminate()。

我还要指出，Scott Meyers 在《更有效的 C++》中讨论了这个主题。他的《Effective C++》和《More Effect C++》是强烈推荐的书籍。

回复收藏 0 原文

怕倦 2024-07-12 00:41:08

如果编译器知道函数永远不会抛出异常（或者至少承诺永远不会抛出异常），“throw()”规范允许编译器在进行代码流分析时执行一些优化。 Larry Osterman 在此简要讨论了这一点：

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

回复收藏 0 原文

毅然前行 2024-07-12 00:41:08

避免 C++ 中的异常规范。您在问题中给出的原因是一个很好的开始。

请参阅 Herb Sutter 的“异常规范的实用视角”。

回复收藏 0 原文

丶视觉 2024-07-12 00:41:08

我认为标准的 except 约定（对于 C++）
异常说明符是 C++ 标准中的一项实验，但大部分都失败了。
例外情况是 no throw 说明符很有用，但您还应该在内部添加适当的 try catch 块，以确保代码与说明符匹配。赫伯·萨特（Herb Sutter）有一个关于这个主题的页面。 Gotch 82

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

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

例外保证

无保证：

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

基本保证：

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

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

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

无投掷保证：

该方法保证不允许任何异常传播到该方法之外。
所有析构函数都应做出此保证。
| 注意：如果在异常已经传播时异常从析构函数中转义
| 应用程序将终止

回复收藏 0 原文

盛夏尉蓝 2024-07-12 00:41:08

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

回复收藏 0 原文

深海不蓝 2024-07-12 00:41:08

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

回复收藏 0 原文

打小就很酷 2024-07-12 00:41:08

异常规范在 C++ 中并不是非常有用的工具。然而，如果与 std::unexpected 结合使用，它们会有很好的用途。

我在一些项目中所做的是带有异常规范的代码，然后使用一个函数调用 set_unexpected() ，该函数将抛出我自己设计的特殊异常。此异常在构造时会获取回溯（以特定于平台的方式），并派生自 std::bad_exception （以允许在需要时传播它）。如果它像通常那样导致终止（）调用，则由what（）打印回溯（以及导致它的原始异常；不难找到），因此我可以获得我的合同所在位置的信息违反了，例如抛出了意外的库异常。

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

回复收藏 0 原文

爱的那么颓废 2024-07-12 00:41:08

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

否则，我认为使用除了 throw() 之外的任何东西来指示它不会抛出任何异常都没有特别有用。

回复收藏 0 原文

电影里的梦 2024-07-12 00:41:08

是的，如果您喜欢内部文档。或者也许编写一个其他人将使用的库，以便他们无需查阅文档就可以知道发生了什么。抛出或不抛出可以被认为是 API 的一部分，几乎就像返回值一样。

我同意，它们对于在编译器中强制执行 Java 风格的正确性并不是很有用，但总比没有或随意的注释好。

回复收藏 0 原文

谈情不如逗狗 2024-07-12 00:41:08

不会。如果您使用它们并且抛出了您未指定的异常（无论是由您的代码还是由您的代码调用的代码），那么默认行为是立即终止您的程序。

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

回复收藏 0 原文

风情万种。 2024-07-12 00:41:07

不。

以下是几个示例：

不可能使用异常规范编写模板代码，
```
模板 
  无效 f( T k ) 
  { 
       T x( k ); 
       xx(); 
  } 
  
```
副本可能会抛出异常，参数传递可能会抛出异常，x() 可能会抛出一些未知的异常。
异常规范往往会禁止可扩展性。
```
virtual void open() throw( FileNotFound ); 
  
```
可能会演变成
```
virtual void open() throw( FileNotFound, SocketNotReady, InterprocessObjectNotImplemented, HardwareUnresponsive ); 
  
```
你真的可以把它写成
<前><代码>抛出（...）
第一个是不可扩展的，第二个是过于雄心勃勃的，第三个正是您编写虚拟函数时的意思。
旧代码
当您编写依赖于另一个库的代码时，您并不真正知道当出现严重错误时它会做什么。
```
int lib_f(); 

  无效 g() 抛出( k_too_small_exception ) 
  {  
     int k = lib_f(); 
     if( k < 0 ) 抛出 k_too_small_exception(); 
  } 
  
```
当 lib_f() 抛出异常时，
g 将终止。（在大多数情况下）这并不是您真正想要的。永远不应该调用 std::terminate() 。让应用程序因未处理的异常而崩溃（您可以从中检索堆栈跟踪）总是比默默地/暴力地死掉要好。

编写返回常见错误并在异常情况下抛出的代码。

错误 e = open( "bla.txt" ); 
  if( e == FileNotFound ) 
      MessageUser("找不到文件 bla.txt"); 
  if( e == 访问被拒绝 ) 
      MessageUser("无法打开bla.txt，因为我们没有读取权限..."); 
  if( e != 成功 ) 
      MessageUser( "由于其他错误而失败，错误代码 = " + itoa( e ) ); 

  尝试 
  { 
     std::vector   k(1000); 
     // ... 
  } 
  catch( const bad_alloc& b ) 
  {  
     MessageUser("内存不足，退出进程"); 
     扔; 
  }

然而，当您的库只是抛出您自己的异常时，您可以使用异常规范来声明您的意图。

No.

Here are several examples why:

Template code is impossible to write with exception specifications,
```
template<class T>
void f( T k )
{
     T x( k );
     x.x();
}
```
The copies might throw, the parameter passing might throw, and x() might throw some unknown exception.
Exception-specifications tend to prohibit extensibility.
```
virtual void open() throw( FileNotFound );
```
might evolve into
```
virtual void open() throw( FileNotFound, SocketNotReady, InterprocessObjectNotImplemented, HardwareUnresponsive );
```
You could really write that as
```
throw( ... )
```
The first is not extensible, the second is overambitious and the third is really what you mean, when you write virtual functions.
Legacy code
When you write code which relies on another library, you don't really know what it might do when something goes horribly wrong.
```
int lib_f();

void g() throw( k_too_small_exception )
{ 
   int k = lib_f();
   if( k < 0 ) throw k_too_small_exception();
}
```
g will terminate, when lib_f() throws. This is (in most cases) not what you really want. std::terminate() should never be called. It is always better to let the application crash with an unhandled exception, from which you can retrieve a stack-trace, than to silently/violently die.

Write code that returns common errors and throws on exceptional occasions.

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;
}

Nevertheless, when your library just throws your own exceptions, you can use exception specifications to state your intent.

回复收藏 0 原文

~没有更多了~

关于作者

骄傲

暂无简介

0 文章

0 评论

23 人气

关注发私信

友情链接

文江博客

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

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

评论（14）

例外保证

无保证：

基本保证：

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

无投掷保证：

Exception Guarantees

No Guarantee:

Basic Guarantee:

Strong Guarantee: (aka Transactional Guarantee)

No Throw Guarantee:

关于作者

相关话题

热门标签

推荐作者

1CH1MKgiKxn9p

ゞ记忆︶ㄣ

JackDx

信远

yaoduoduo1995

霞映澄塘

友情链接

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

如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

评论（14）

例外保证

无保证：

基本保证：

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

无投掷保证：

Exception Guarantees

No Guarantee:

Basic Guarantee:

Strong Guarantee: (aka Transactional Guarantee)

No Throw Guarantee:

关于作者

相关话题

热门标签

推荐作者

1CH1MKgiKxn9p

ゞ记忆︶ㄣ

JackDx

信远

yaoduoduo1995

霞映澄塘

友情链接

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。