异常处理(EH)似乎是当前的标准,通过搜索网络,我找不到任何新的想法或方法来改进或取代它(好吧,存在一些变化,但没有什么新奇的)。

尽管大多数人似乎忽略了它或只是接受它,EH有一些巨大的缺点:异常对代码是不可见的,它创建了许多许多可能的退出点。软件的Joel写了一篇关于它的文章。与goto的对比非常完美,这让我再次思考EH。

我尽量避免EH,只使用返回值,回调或任何符合目的的东西。但是,当您必须编写可靠的代码时,现在就不能忽略EH了:它从new开始,可能会抛出异常,而不只是返回0(就像以前一样)。这使得几乎每一行c++代码都容易出现异常。然后在c++基本代码中抛出异常的地方更多……STD lib可以这样做,等等。

这感觉就像在摇摇欲坠的地面上行走。因此,现在我们不得不关注异常!

但这很难,真的很难。你必须学会编写异常安全的代码,即使你有一些这方面的经验,仍然需要仔细检查每一行代码的安全性!或者您开始到处放置try/catch块,这会使代码变得混乱,直到达到不可读的状态。

EH replaced the old clean deterministical approach (return values..), which had just a few but understandable and easily solveable drawbacks with an approach that creates many possible exit points in your code, and if you start writing code that catches exceptions (what you are forced to do at some point), then it even creates a multitude of paths through your code (code in the catch blocks, think about a server program where you need logging facilities other than std::cerr ..). EH has advantages, but that's not the point.

我真正的问题是:

你真的写异常安全的代码吗? 您确定最后的“生产就绪”代码是异常安全的吗? 你能确定这是真的吗? 你知道和/或实际上使用有效的替代方法吗?


当前回答

如果假设“任何行都可以抛出”,就不可能编写异常安全的代码。异常安全代码的设计主要依赖于某些契约/保证,你应该在你的代码中期望、观察、遵循和实现这些契约/保证。拥有保证永不抛出的代码是绝对必要的。还有其他类型的异常保证。

换句话说,创建异常安全代码在很大程度上是程序设计的问题,而不仅仅是简单的编码问题。

其他回答

如果假设“任何行都可以抛出”,就不可能编写异常安全的代码。异常安全代码的设计主要依赖于某些契约/保证,你应该在你的代码中期望、观察、遵循和实现这些契约/保证。拥有保证永不抛出的代码是绝对必要的。还有其他类型的异常保证。

换句话说,创建异常安全代码在很大程度上是程序设计的问题,而不仅仅是简单的编码问题。

先不考虑SEH和c++异常之间的混淆,您需要意识到异常可能在任何时候抛出,并在编写代码时牢记这一点。异常安全的需求在很大程度上推动了RAII、智能指针和其他现代c++技术的使用。

如果遵循公认的模式,编写异常安全的代码就不是特别困难,事实上,它比编写在所有情况下都能正确处理错误返回的代码要容易得多。

是的,我尽了最大的努力来编写异常安全的代码。

这意味着我要注意哪些行可以抛出。不是每个人都能做到,记住这一点至关重要。关键在于真正考虑并设计代码以满足标准中定义的异常保证。

这个操作可以编写为提供强异常保证吗?我必须满足于最基本的吗?哪些行可能抛出异常,我如何确保如果它们这样做,它们不会破坏对象?

不过,我真的很喜欢使用Eclipse和Java (Java新手),因为如果缺少EH处理程序,它会在编辑器中抛出错误。这使得忘记处理异常变得更加困难……

另外,使用IDE工具,它会自动添加try / catch块或另一个catch块。

在c++中编写异常安全代码并不是使用大量的try {} catch{}块。它是关于记录您的代码提供了什么样的保证。

我推荐大家阅读Herb Sutter的《每周大师》系列,特别是第59、60和61期。

总之,你可以提供三种级别的异常安全:

基本:当您的代码抛出异常时,您的代码不会泄漏资源,对象仍然是可破坏的。 强:当您的代码抛出异常时,它将保持应用程序的状态不变。 不抛出:你的代码永远不会抛出异常。

就我个人而言,我是很晚才发现这些文章的,所以我的很多c++代码肯定不是异常安全的。