我处理错误的方法是,有三种根本错误:

• An odd situation that can be handled at the error site. This might be if a user inputs an invalid input at a command line prompt. The correct behavior is simply to complain to the user and loop in this case. Another situation might be a divide-by-zero. These situations aren t really error situations, and are usually caused by faulty input.
• A situation like the previous kind, but one that can t be handled at the error site. For instance, if you have a function that takes a filename and parses the file with that name, it might not be able to open the file. In this case, it can t deal with the error. This is when exceptions shine. Rather than use the C approach (return an invalid value as a flag and set a global error variable to indicate the problem), the code can instead throw an exception. The calling code will then be able to deal with the exception - for instance to prompt the user for another filename.
• A situation that Should Not Happen. This is when a class invariant is violated, or a function receives an invalid paramter or the like. This indicates a logic failure within the code. Depending on the level of failure, an exception may be appropriate, or forcing immediate termination may be preferable (as assert does). Generally, these situations indicate that something has broken somewhere in the code, and you effectively cannot trust anything else to be correct - there may be rampant memory corruption. Your ship is sinking, get off.

简言之,如果你有问题,可以例外处理,但你可以在你通知的地方处理。 你们不能处理的问题只能是杀害方案;你能够处理权利问题,应该简单地处理。

I read some of the answers here. I m still amazed on what all this confusion is about. I strongly disagree with all this exceptions==spagetty code. With confusion I mean, that there are people, which don t appreciate C++ exception handling. I m not certain how I learned about C++ exception handling -- but I understood the implications within minutes. This was around 1996 and I was using the borland C++ compiler for OS/2. I never had a problem to decide, when to use exceptions. I usually wrap fallible do-undo actions into C++ classes. Such do-undo actions include:

• creating/destroying a system handle (for files, memory maps, WIN32 GUI handles, sockets, and so on)
• setting/unsetting handlers
• allocating/deallocating memory
• claiming/releasing a mutex
• incrementing/decrementing a reference count
• showing/hiding a window

Than there are functional wrappers. To wrap system calls (which do not fall into the former category) into C++. E.g. read/write from/to a file. If something fails, an exception will be thrown, which contains full information about the error.

随之而来的例外情况是,在失败后增加更多的信息。

Overall C++ exception handling leads to more clean code. The amount of code is drasticly reduced. Finally one can use a constructor to allocate fallible resources and still maintain a corruption free environment after such a failure.

One can chain such classes into complex classes. Once a constructor of some member/base object is exectued, one can rely on that all other constructors of the same object (executed before) executed successfully.

与传统建筑相比,例外是一种非常罕见的流动控制方法(流动、租赁、功能等)。 正常控制流动结构(流动、功能要求等)能够处理所有正常情况。 如果你发现自己是例行发生的例外情况,那么你或许需要考虑一下贵国的法典的结构。

但是,某些类型的错误无法与正常建筑一起轻易处理。 低水平可检测到中世纪的失败(如资源分配失败),但可能无法处理,因此,如果说不适当,简单不过。 这些类型的失败一般需要以高得多的级别处理(例如,除案卷外、记录错误、空档)。 试图通过传统方法(如回归价值)报告类似错误是荒谬的,容易发生错误。 此外,它还将间接费用注入中层的抗灾能力,以应付这一荒谬的异常故障。 间接费用分散了这些软件的客户,要求他们担心自己无法控制的问题。 例外情况为非当地处理大差错提供了一种途径,这些大差错在发现问题与该问题的手持之间最为看不见。

如果客户打电话ParseInt,并附上插图,则直接打电话者可能注意错误,并知道如何做。 因此,你设计了ParseInt,以换取类似的东西。

另一方面,如果是<代码> ParseInt之所以失败,是因为它无法分配缓冲,因为记忆非常分散,因此打电话的人没有了解这方面的情况。 这种异常的错误将不得不加以掩饰,并可能影响到处理这些根本失败的一些层面。 这对每个人征税(因为他们不得不在自己的APIC中考虑到错误通过机制)。 一种例外情况是,可以绕过这些层次(尽管仍然确保进行必要的清理)。

当你重写低层次的法典时,很难决定何时使用传统方法,何时放弃例外。 低级法典必须作出决定(增长或无)。 但是,这部高层次的法典确实知道什么是预期的,什么是例外。

C++有若干原因。

首先,它经常难以看到有例外情形(因为它们几乎可以被抛在一边),因此,从COME发言中可以发现捕获块。 这比一项目标更糟,因为在一项目标中,你知道你从哪里(发言,而不是一些随机的传说)以及你回去(标签)。 它们基本上是一种潜在的资源安全模式,即C s setjmp()和长jmp(),任何人都不想使用。

第二,C++确实有垃圾收集,因此,C++级拥有资源,在他们的骑手里拿走。 因此,在C++例外处理系统中,必须管理范围上的所有反应堆。 用GC语言,没有真正的建筑商,如Java,将例外搁置起来远比累。

第三,C++社区,包括Bjarne Stroustrup和标准委员会以及各种汇编作者,一直认为例外应当是例外。 总的来说,这不利于语言文化。 执行所依据的假设是,例外情况很少。 较好的书籍将例外情况作为例外处理。 良好的源代码使用少数例外。 良好的C++开发商将例外情况作为例外处理。 反之,你想有一个好的理由,我看到的所有理由都是为了保持这些例外。

这是一种使用例外作为控制流动的坏例子:

int getTotalIncome(int incomeType) {
   int totalIncome= 0;
   try {
      totalIncome= calculateIncomeAsTypeA();
   } catch (IncorrectIncomeTypeException& e) {
      totalIncome= calculateIncomeAsTypeB();
   }

   return totalIncome;
}

情况非常糟糕,但应当写:

int getTotalIncome(int incomeType) {
   int totalIncome= 0;
   if (incomeType == A) {
      totalIncome= calculateIncomeAsTypeA();
   } else if (incomeType == B) {
      totalIncome= calculateIncomeAsTypeB();
   }
   return totalIncome;
}

第二个例子显然需要一些调整(如采用设计模式战略),但充分表明,例外情况并非控制流动。

例外情况还涉及一些业绩处罚,但业绩问题应当遵循以下规则:“最佳地位是所有邪恶的根源”。

1. Maintainability: As mentioned by people above, throwing exceptions at a drop of a hat is akin to using gotos.
2. Interoperability: You can t interface C++ libraries with C/Python modules (atleast not easily) if you are using exceptions.
3. Performance degradation: RTTI is used to actually find the type of the exception which imposes additional overhead. Thus exceptions are not suitable for handling commonly occurring use cases(user entered int instead of string etc).

我要说的是,例外情况是一种机制,使你摆脱目前的情况(从最简单意义上讲,现在的 st脚,但比这更加安全)。 结构最严密的方案拟订工作必须去做。 为了以打算使用例外的方式使用这些例外情况,你不得不在你现在能够继续做些什么的情况下这样做,而且你现在可以不处理。 因此,例如,当用户口号错误时,你可以继续找回假。 但是,如果国际调查小组的子系统报告说,它甚至能够促使用户使用,那么仅仅退回“log失败”就是错误的。 目前的法典水平根本不知道需要做什么。 因此,它利用一种例外机制,将责任交给上述可能知道要做的事情的人。