C++中try/catch块的用法
一般来说，我倾向于使用try/catch代码，该代码具有多个失败点，其中失败点具有共同的处理程序。C++中try/catch块的用法
根据我的经验，这通常是在执行某些操作之后执行某些操作或输出之前限定输入或上下文的代码。
我收到了来自文献和同事的建议，尽量减少这些块中的代码，并且我接受这个建议。
我想了解更多的关于上述建议的基础：
- 什么开销的本质是什么？
- 是否有最近的开发指南解决try/catch块的推荐使用（或避免）？
- 更快的处理器和更现代的编译器能够缓解try/catch问题的多少？
在此先感谢您的帮助，
AJ
以我的经验用try/catch块，最大的问题是，我们常常试图捕获异常也一般。例如，如果我用捕获（...）的try/catch块封装我的主函数，我基本上不想让我的程序崩溃抛出异常的b/c。
这种方法的问题，因为我看到它是两倍。 1）当我正在测试和调试时，我没有看到任何错误，我没有机会修复它们。 2）这是一种懒惰的方式。与其考虑可能出现的问题并找出边缘情况是什么，我只是想尽量避免失败。尝试不失败与尝试成功有很大的不同。
你总是可以赶上并重新抛出。注意如果一个异常转义了main（），它将在堆栈解开时定义实现（所以析构函数可能不会被调用）。因此，我总是抓住（...）并登录main并重新抛出，以便获取windows错误消息。 – 2009-06-04 18:56:01
我发现了a technical report on C++ performance（pdf警告），其中包含有关例外的部分。你可能会觉得它很有趣。我有一些同事相信在try/catch块中的每条指令都有开销，但这份技术报告似乎并不支持这个想法。
在大多数语言中，通过常规方法进入和退出try/catch块是免费的，只有当异常处理程序查找异常处理位置时才会引发异常。
取决于编译器。你为什么不用一个try-catch块和一个没有它的类似函数编写一个简单的函数，并比较生成的机器码？
在C++中，成本取决于实现。一般来说，有两种方法来实现例外：
第一种是“表格”方法。编译器建立一组表查找，在抛出异常的地方，去哪里。抛出异常时，必须搜索每个表中的调用堆栈，直到找到能够捕获此异常的东西。由于这是所有基于运行时的，所以进入或退出try catch不会产生任何惩罚（好），但抛出异常涉及潜在的许多查找，产生更慢的抛出。我个人更喜欢try-catch-try-try-catch，因为异常应该是非常罕见的情况。如果必须存储表格，这也会使可执行文件变大。
秒是“代码”的方法。每次代码进入try catch块时，从概念上讲，块的位置被压入堆栈。这会在进入和退出try-catch块时产生成本，但是，当引发异常时，运行时机制可以快速弹出堆栈以找到要去的地方。所以，抛出异常（更快？），但现在进入一个块有成本。将一个try catch块放在一个低级别的循环中会产生很大的开销。
你将不得不检查你的具体编译器，看看他们使用哪一个。
在C++中，您不应该使用try/catch块来执行清理。相反，您可能想要使用模板来执行资源采集。
的auto_ptr的是一个[衰]例如
同步锁，在那里你存储一个互斥体的状态变量，使用局部变量（模板或者在普通类）来执行.acquire（）/。释放（）方法。
您做的越多，您就越不必担心在特殊情况下手动释放对象。 C++编译器会为你做。
我不确定我是否理解这个问题。你担心try/catch块的性能吗？或者询问使用try/catch来处理输入验证或什么？ – jalf 2009-06-04 15:54:50
Dupe of http://stackoverflow.com/questions/43253/measuring-exception-handling-overhead-in-c其他许多人 – 2009-06-04 16:18:37