我理解try
并catch()
用于异常处理,以防在某些情况下程序中发生错误或崩溃。我也了解它们的工作原理。但是为什么要使用try
andcatch()
呢?为什么不只使用一个if()
查找某个案例的语句,如果该案例为真,它会cout << //error code
呢?
5 回答
异常处理:
- 可以与没有机会返回单独错误代码的构造函数和运算符一起使用(它们可以将对象设置为某种错误状态 - 这意味着进一步的内存使用 - 但客户端代码还必须记住稍后检查该错误状态)
- 例如:用户定义类型 - 类
X
- 支持符号x1 = x2 + x3
- 哪里可以返回错误代码?
- 例如:用户定义类型 - 类
- 可以在初始化列表中构造特定的类/结构数据成员时加入 - 避免进一步的数据成员构造可能注定或浪费;相比之下,显式错误处理只能在构造函数主体的后期进行
- 更隐含——强调代码正常的成功流程,这样可以使其更简洁、可读、可维护
- 因数不同 - 可以在一个地方捕获来自许多地方的异常,这有时会使错误处理代码本身更加简洁、可读、可维护
- 在错误处理会重复的情况下,简洁的好处实际上可以导致更可靠的错误处理
- 通常使用自己的内存区域,独立于堆栈用于局部变量、函数参数、保存CPU寄存器和返回地址等;这意味着即使剩余堆栈内存小于异常对象,throw 语句也可以直接在该内存区域中可靠地构造异常对象(尽管这是一个实现细节并且标准不保证)
- 具有不同的性能配置文件,因此在某些情况下两者都可以更快
- 促进更丰富的错误信息从低级代码向上传播到中间代码,您可能不“拥有”或希望/能够更改以传播错误代码 C 风格,到处理点
try...catch
做得更多。它展开堆栈,该堆栈调用自try
进入以来所有自动分配的对象的析构函数。如果您按照建议的方式执行此操作,则必须手动跟踪这些对象,否则您会遇到内存问题(泄漏、覆盖、过时的指针、双重删除)
另一个原因是:您编写的代码也可能被其他人用作更大项目的一部分。并且由于使用内置的异常处理例程是一种标准,大型项目的维护者期望您同样处理您的异常,以便可以在上层正确完成异常处理 - 更不用说使用标准的事实作为错误输出的输出是一种可疑的做法(例如,它可能被抑制;或者根本不被使用)。
UPD:我有点误解了你的问题。我描述的原因实际上证明了手动抛出异常是合理的,但不使用try...catch
块。
我将引用我的一位英雄,ZeroMQ 成名的 Martin Sústrik 的话来回答,摘自http://www.250bpm.com/blog:4上的博客条目
然而,当您的目标是保证不会发生未定义的行为时,避免直接失败的好处就变成了一场噩梦。引发异常和处理异常之间的解耦使得在 C++ 中避免失败变得如此容易,这使得几乎不可能保证程序永远不会运行信息未定义的行为。
然后补充一点,我发现我使用 try/catch 进行非常高级别的重启层,比其他任何东西都多。补充一下,我的意见真的不重要。我相信,如何以及为什么使用异常处理背后的选择与喜欢绿色多于蓝色的选择非常相似。个人的,其他人的任何意见都不可能改变它。
The question poses a false dichotomy. In Java and C# try
-catch
competes with if
for cleanup on failure. In C++ it's mainly RAII technique (using destructors and single phase construction) that competes with if
for cleanup on failure.
If the question had been about using exceptions versus using if
, then it would have been more sensible and relevant to ordinary C++ programming.