为什么在C++中使用try-and-catch(）

异常处理：

• 可以与没有机会返回单独错误代码的构造函数和运算符一起使用（他们可以将对象设置为某种错误状态，这意味着需要进一步使用内存，但客户端代码也必须记住稍后检查该错误状态）
  • 例如：用户定义的类型类X-支持符号x1 = x2 + x3-哪里可以返回错误代码
• 可以在初始化程序列表中构造特定的类/结构数据成员时启动，从而避免可能注定要失败或浪费的进一步数据成员构造；相反，显式错误处理只有在构造函数主体中才有可能
• 更含蓄——强调正常的成功代码流，这可以使其更简洁、可读、可维护
• 考虑因素不同-来自多个地方的异常可以在一个地方捕获，这有时会使错误处理代码本身更加简洁、可读和可维护
• 在错误处理重复的情况下，简洁的好处实际上可以带来更可靠的错误处理
• 通常使用自己的内存区域，独立于用于本地变量、函数参数、保存CPU寄存器和返回地址等的堆栈。；这意味着，即使剩余的堆栈内存小于异常对象，throw语句也可以直接在该内存区域中可靠地构造异常对象（尽管这是一个实现细节，标准不保证）
• 具有不同的性能配置文件，因此在某些情况下可以更快
• 有助于从低级代码向上传播更丰富的错误信息到中间代码，您可能不"拥有"或希望/能够更改为传播错误代码的C样式，直至处理

try...catch做得更多。它解开了自输入try以来为所有自动分配的对象调用析构函数的堆栈。如果按照建议的方式进行操作，则必须手动跟踪这些对象，否则会出现内存问题（泄漏、覆盖、过时指针、双重删除）

另一个原因是：您编写的代码可能会被其他人用作更大项目的一部分。由于使用内置的异常处理例程是一种标准，因此大型项目的维护人员希望您也能处理异常，以便在更高级别上正确地完成异常处理——更不用说使用标准输出作为错误输出是一种可疑的做法（例如，它可能会被抑制；或者根本不使用）。

乌干达人民国防军：我有点误解了你的问题。我所描述的原因实际上证明了手动异常抛出的合理性，但没有使用try...catch块。

我将引用我的英雄之一、ZeroMQ名人马丁·苏斯特里克的一句话作为回答，这句话取自http://www.250bpm.com/blog:4

然而，当你的目标是确保没有未定义的行为发生时，避免直接失败的好方法就变成了噩梦。在C++中，引发异常和处理异常之间的解耦使得避免故障变得如此容易，这使得几乎不可能保证程序永远不会运行信息未定义的行为。

然后补充一句，我发现我对非常高的重启层使用try/catch，比其他任何东西都多。补充说，我的意见真的无关紧要。我相信，如何以及为什么使用异常处理背后的选择与选择更喜欢绿色而不是蓝色非常相似。个人的，没有任何来自其他人的输入可能会改变它。

这个问题提出了一个错误的二分法。在Java和C#中，try-catch与if竞争故障清理。在C++中，主要是RAII技术（使用析构函数和单相构造）与if竞争故障清理。

如果问题是使用异常而不是使用if，那么它会更明智，并且与普通C++编程更相关。