问题标签 [exception-specification]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
c++ - 是否可以在 C++ 虚拟(纯)类成员中提供异常?
如果有怎么办?
我知道如何为成员提供异常规范,例如
所以method
只有投掷SOMEException
。如果我想确保SOMEClass
throw SOMEException
for的子类pure_method
,是否可以添加异常规范?这种方法是否可行,还是我需要更多地了解异常和抽象方法以找出为什么可以(不能)完成?
c++ - 是否有一个普遍接受的习惯用法来指示 C++ 代码可以抛出异常?
我在使用 C++ 代码时遇到了一些问题,调用者出乎意料地抛出了异常。阅读您正在使用的模块的每一行以查看它是否抛出异常以及如果是,那么是什么类型的异常并不总是可能或实际的。
是否存在处理此问题的既定习语或“最佳实践”?
我想到了以下几点:
在我们的 doxygen 文档中,我们可以在每个预期会引发异常的函数中添加注释及其类型。
- 优点:简单。
- 缺点:受用户错误的影响。
为了安全,我们可以有一个应用程序范围
try/catch(...)
。- 优点:我们不会再有任何未捕获的异常。
- 缺点:异常在距离抛出很远的地方被捕获。很难弄清楚该做什么或出了什么问题。
使用异常规范
- 优点:这是处理这个问题的语言认可的方式。
- 缺点:需要重构问题库以使其有效。在编译时未强制执行,因此违规会变成运行时问题,这是我要避免的!
这些方法的任何经验,或我不知道的任何其他方法?
c++ - 恢复 VC++ 9.0 下的异常规范行为
我正在处理严重依赖于语言标准中描述的异常规范行为的旧代码。即,在违反下述形式的异常规范时调用 std::unexpected()。
Nothrow 规范确实保证不会抛出,但是throw(T)规范预计会被设计和……所违反,因为标准期望同样多,并提供了一种处理它的机制。
其原因与设计人员决定使用 EH 作为除异常处理之外的错误处理机制(由其自己的错误类层次结构控制)有关。EH 中呈现的成语与他们的需求密切相关,他们采取了最省力的方式。考虑到系统的规模和复杂性,这至少是我的看法,而且对我来说并不是特别令人震惊。
然而,我现在的任务是包含新的和不相关的功能,并且由于与 8.0 中引入的异常规范相关的标准存在偏差,因此代码在 VC++ 9.0 下的行为与预期不同。(参考:微软)
我试图找到一种强制标准行为的方法。希望编译器提供后备。但是没有。
我是否运气不好,需要更改在 350,000 行代码上运行的正确编写的符合标准的代码,并具有完全开发的错误处理类层次结构?或者你能想出一种方法来帮助我强制 std::unexpected() 行为吗?
编辑: 我提供了一些背景信息。有问题的系统是一个学年日历生成器,为一所学校服务,分布在 4,000 多名学生中,我不确定其中的一些数字,6 个年级和约 190 个班级,外加 12 个虚拟(远程教学)类。MINGW 与 VC++ 8.0 或 9.0 以外的任何编译器一样,都是不可能的。这是由于有关为该国教育系统服务的软件的规定。
代码所需的更改正是为了适应虚拟类的引入,这些虚拟类具有用于日历生成的截然不同的模式。然后我碰到了这个问题。该软件在日历生成过程的几个部分大量使用异常机制,作为通过意外()映射(保存和恢复)和 bad_exception 映射来控制工作流的一种手段,这些映射都不能在 VC++ 下工作。就纯粹个人而言,我发现该机制实际上非常优雅,即使完全不常见。但我离题了。
c++ - 覆盖虚函数时的异常说明
考虑以下代码:
编译时,它说派生类 B 与 A 相比具有更宽松的抛出说明符。这有什么重要性?如果我们尝试交换它们的异常规范,使得 A::f() 抛出 int 和 double 而 B::f() 只抛出 int,则不会出现错误。
c++ - 异常规范
我知道这个特性在 C++0x 中会被弃用,但对于我这个新手来说,拥有它似乎是个好主意。谁能向我解释为什么不是一个好主意?
c++ - 如何摆脱“C++ 异常规范被忽略”警告
我最近得到了一个别人实现的dll。我必须在我的应用程序中使用它。在他们的类的头文件中,他们有函数声明
现在当我编译它时收到警告,
忽略 C++ 异常规范,除非指示函数不是 _declspec(nothrow)
我阅读了MSDN - 文档但无法清楚地理解它。另外,我不想仅仅因为它出现就禁用警告。我想知道我做错了什么而不是禁用它。
我认为我的函数,说 myfunc()
从 dll访问它func1()
没有那个异常规范列表。因此,我也尝试在我的函数中使用相应的异常规范列表,
但我仍然收到警告。该警告的全部内容是什么以及如何摆脱它?我在 Windows XP 中使用 Qt 4.5。
c++ - 异常规范如何影响虚拟析构函数覆盖?
C++ 标准规定了以下关于具有异常规范的虚函数:
如果虚函数具有异常规范,则在任何派生类中覆盖该虚函数的任何函数的所有声明(包括定义)都应仅允许基类虚函数的异常规范(C + +03 §15.4/3)。
因此,以下格式不正确:
(1) 此规则是否适用于析构函数?也就是说,下面的格式是否正确?
(2) 该规则如何应用于隐式声明的析构函数?也就是说,下面的格式是否正确?
虽然在一般情况下永远不应该编写异常规范,但这个问题具有实际意义,因为std::exception
析构函数是虚拟的并且具有空的异常规范。
由于不允许从析构函数中抛出异常是一种很好的做法,因此为了简化任何示例,我们假设析构函数要么允许所有异常(即,它没有异常规范),要么不允许异常(即也就是说,它有一个空的异常规范)。
c++ - 基于经验的 C++ 错误特征
最近一位同事问我对在 C++ 代码中使用异常规范的看法,我能够挖掘出 Herb Sutter 的这篇文章:A Pragmatic Look at Exception Specifications。与 Herb Sutter 的大多数文章一样,这篇文章是一本教育读物,但简短的回答是“不要那样做”。
在总结中,他提到了一首题为“实施前的夜晚”的诗,其中,标准委员会实际上在最后一刻屈服于用户的要求,添加了一个功能,结果发现当它做了什么是要求,它并没有真正做到他们想要的。是的,异常规范符合该法案。正如他所说,“当时这个功能似乎是个好主意,这正是一些人所要求的。” 如果这还不够,他然后访问“出口”,结果类似的悲惨结果。
所以问题是这样的:如果你不想流泪,C++ 的什么“特性”被证明是坏的,不应该被使用。这可能是主观争吵的牺牲品,但我希望人们会引用一个特定的体验,即部署该功能只是为了引起可衡量的问题。更好的是像 Sutter(或任何深入参与该标准的人)这样的领导者引用文章,警告人们不要使用某个功能。
c++ - 从 C++11 中的 std::exception 派生时的异常规范
我有一个异常类如下:
在 GCC 4.4 下使用 -Wall -std=c++0x 编译时
错误:'virtual const char* InvalidPathException::what() const' 的更宽松的抛出说明符
错误:覆盖 'virtual const char* std::exception::what() const throw ()'
也非常正确,因为我正在覆盖确实具有异常说明符std::exception
的 's方法。但正如人们经常被告知的那样,我们不应该使用异常说明符。据我了解,它们在 C++11 中已被弃用,但显然尚未在带有 -std=c++0x 的 GCC 中。what()
throw()
所以我现在对最好的方法感兴趣。在我正在开发的代码中,我确实关心性能,因此担心经常提到的开销throw()
,但实际上这种开销如此严重吗?我是否认为我只会在what()
实际调用时遭受它,这只会在抛出这样的异常之后(同样对于从 std::exception 继承的其他方法都具有throw()
说明符)?
或者,有没有办法解决 GCC 给出的这个错误?