我经常看到/听到人们说例外情况应该很少使用，而永远不要解释原因。尽管这可能是正确的，但基本原理通常是一个轻浮的说法：“由于某种原因，它被称为例外”，在我看来，这似乎是一种受尊敬的程序员/工程师不应接受的解释。
有一系列问题可以使用异常来解决。为什么将它们用于控制流是不明智的？对它们的使用格外保守的背后的哲学是什么？语义学？性能？复杂？美学？惯例？
之前我已经看过一些性能分析，但是分析的水平与某些系统相关，而与其他系统无关。
同样，我不一定不同意在特殊情况下应该保存它们，但是我想知道共识的基础是什么（如果存在这种情况）。
Answers:
摩擦的主要点是语义。许多开发人员滥用异常，并抓住每一个机会。这个想法是在某些特殊情况下使用异常。例如，错误的用户输入不会被视为异常，因为您希望这种情况会发生并为此做好准备。但是，如果您尝试创建文件并且磁盘上没有足够的空间，那么可以，这是一个明确的例外。
另一个问题是，通常会抛出并吞下异常。开发人员使用此技术可以简单地使程序“静音”，并使其运行尽可能长的时间，直到完全崩溃为止。这是非常错误的。如果您不处理异常，如果您没有通过释放一些资源来做出适当的反应，或者您没有记录异常的发生或至少没有通知用户，那么您就没有使用异常的含义。
直接回答您的问题。很少使用例外，因为例外情况很少见，例外的代价很高。
很少，因为您不希望每次按下按钮或每次用户输入格式错误时程序都会崩溃。说，数据库可能突然无法访问，磁盘上可能没有足够的空间，您依赖的某些第三方服务处于脱机状态，这一切都可能发生，但很少见，这些显然是例外情况。
昂贵，因为抛出异常会中断正常的程序流。运行时将展开堆栈，直到找到可以处理异常的适当异常处理程序为止。它还将一直收集调用信息，以传递给处理程序将接收到的异常对象。这一切都有成本。
这并不是说使用例外（微笑）不会有例外。有时，如果引发异常而不是通过多层转发返回代码，则可以简化代码结构。作为一条简单的规则，如果您希望某个方法经常被调用并且在一半的时间内发现某种“异常”情况，那么最好找到另一个解决方案。但是，如果您希望大多数时候都能正常运行，而这种“例外”情况只能在一些罕见的情况下出现，那么抛出异常就可以了。
@Comments：如果可以使代码更简单，更轻松，则可以在某些异常情况下使用异常。这个选项是开放的，但我会说它在实践中很少见。
为什么将它们用于控制流是不明智的？
因为异常会破坏正常的“控制流”。引发异常，程序的正常执行被放弃，有可能使对象处于不一致状态，并使某些开放资源无法释放。当然，C＃具有using语句，该语句将确保即使从using主体抛出异常，也将处置该对象。但是，让我们暂时从语言中进行抽象。假设框架不会为您布置对象。您手动进行。您具有一些用于请求和释放资源和内存的系统。您在系统范围内有协议，由谁负责在什么情况下释放对象和资源。您有如何处理外部库的规则。如果程序遵循正常的操作流程，则效果很好。但是突然在执行过程中，您抛出了异常。一半的资源没有释放。尚未请求一半。如果该操作本来应该是事务性的，那么它将被破坏。您处理资源的规则将不起作用，因为负责释放资源的那些代码部分将无法执行。如果其他人想使用这些资源，他们可能会发现它们处于不一致状态并崩溃，因为他们无法预测这种特殊情况。
假设您希望方法M（）调用方法N（）进行一些工作并安排一些资源，然后将其返回给M（），后者将使用它并进行处理。精细。现在在N（）中出了点问题，并在M（）中引发了您没有想到的异常，因此该异常冒泡到顶部，直到它可能被某种方法C（）捕获为止，该方法根本不知道到底发生了什么N（）中的内容以及是否以及如何释放一些资源。
通过抛出异常，您可以创建一种使程序进入许多难以预测，难以理解和处理的新的不可预测的中间状态的方法。它有点类似于使用GOTO。设计一个可以随机将其执行从一个位置跳转到另一个位置的程序非常困难。也将很难维护和调试它。当程序变得越来越复杂时，您将失去对何时何地进行修复的更少了解。
尽管“在特殊情况下抛出异常”是一个很好的答案，但您实际上可以定义这些情况是什么：当满足先决条件而后继条件不能满足时。这使您可以编写更严格，更严格和更有用的后置条件，而无需牺牲错误处理；否则，您必须毫无例外地更改后置条件，以允许所有可能的错误状态。
关于可以用C ++编写的每个类的每个构造函数，您几乎没有什么要说的，但是有几件事。其中最主要的是构造的对象（即构造函数返回成功的对象）将被破坏。 您不能修改此后置条件，因为该语言假定该条件是正确的，并将自动调用析构函数。 （从技术上讲，您可以接受未定义行为的可能性，该语言对此不作任何保证，但这在其他地方可能会更好地涵盖。）
当构造函数无法成功时引发异常的唯一替代方法是修改类的基本定义（“类不变”）以允许有效的“ null”或僵尸状态，从而允许构造函数通过构造僵尸来“成功” 。
此僵尸修改的一个示例是std :: ifstream，您必须始终检查其状态才能使用它。例如，因为std :: string不存在，所以始终保证您可以在构造后立即使用它。想象一下，如果您必须编写如本例这样的代码，并且如果忘记了检查僵尸状态，那么您要么默默地得到错误的结果，要么会破坏程序的其他部分：
string s = "abc";
if (s.memory_allocation_succeeded()) {
do_something_with(s); // etc.
}
甚至为该方法命名也是一个很好的例子，说明如何必须为情况字符串修改类的不变式和接口，因此无法预测或处理自身。
我们来看一个常见的例子：验证用户输入。仅仅因为我们要允许失败的输入并不意味着解析函数需要将其包括在其后置条件中。但是，这确实意味着我们的处理程序需要检查解析器是否失败。
// boost::lexical_cast<int>() is the parsing function here
void show_square() {
using namespace std;
assert(cin); // precondition for show_square()
cout << "Enter a number: ";
string line;
if (!getline(cin, line)) { // EOF on cin
// error handling omitted, that EOF will not be reached is considered
// part of the precondition for this function for the sake of example
//
// note: the below Python version throws an EOFError from raw_input
// in this case, and handling this situation is the only difference
// between the two
}
int n;
try {
n = boost::lexical_cast<int>(line);
// lexical_cast returns an int
// if line == "abc", it obviously cannot meet that postcondition
}
catch (boost::bad_lexical_cast&) {
cout << "I can't do that, Dave.\n";
return;
}
cout << n * n << '\n';
}
不幸的是，这显示了两个示例，这些示例说明了C ++的作用域如何要求您破坏RAII / SBRM。Python中没有这个问题的示例，显示了我希望C ++拥有的一些东西– try-else：
# int() is the parsing "function" here
def show_square():
line = raw_input("Enter a number: ") # same precondition as above
# however, here raw_input will throw an exception instead of us
# using assert
try:
n = int(line)
except ValueError:
print "I can't do that, Dave."
else:
print n * n
前提条件不必严格检查-违反前提条件总是表示逻辑失败，这是调用方的责任-但如果您检查了前提条件，则抛出异常是适当的。（在某些情况下，返回垃圾或使程序崩溃更合适；尽管这些动作在其他情况下可能是非常错误的。如何最好地处理未定义的行为是另一个主题。）
特别是，将stdlib异常层次结构的std :: logic_error和std :: runtime_error分支进行对比。前者通常用于违反先决条件，而后者更适合于违反先决条件。
goto适用于异常。它们经常跳过多个例程和源文件中潜在的大量代码。通过阅读中间源代码，这并不总是显而易见的。（使用Java。）int f() { char* s = malloc(...); if (some_func() == error) { free(s); return error; } ... }无论是手动执行还是通过异常执行，您都必须付出代价来释放堆栈。你不能比较使用异常没有错误处理可言。
在某种程度上，引发异常类似于goto语句。这样做是为了进行流控制，然后您将获得难以理解的意大利面条式代码。更糟糕的是，在某些情况下，您甚至不知道跳转的确切位置（即，如果您没有在给定的上下文中捕获异常）。这公然违反了增强可维护性的“最小惊喜”原则。
catch，尽管在这种情况下，您最好还是自称std::terminate()。总体而言，在我看来，这种说法似乎是“从不使用异常”，而不是“仅很少使用异常”。
异常使您更难以推理程序状态。例如，在C ++中，与不必使用某些函数相比，您必须做更多的思考以确保您的函数具有严格的异常安全性。
原因是没有例外，函数调用可以返回，也可以先终止程序。除异常外，函数调用可以返回，也可以终止程序，或者可以跳转到某个地方的catch块。因此，您不再仅仅通过查看您前面的代码就可以遵循控制流程。您需要知道调用的函数是否可以抛出。您可能需要知道可以引发什么以及在何处捕获它，这取决于您是否关心控件在哪里，还是只在乎它离开当前作用域。
因此，人们说“除非情况真的很特殊，否则不要使用例外”。当您开始使用它时，“真正的例外”表示“发生了一些情况，用错误的返回值处理它的好处被成本所抵消”。因此，是的，这是一个空洞的声明，尽管一旦您有了“真正的例外”的直觉，它就会成为一个好的经验法则。当人们谈论流控制时，它们意味着本地推理（不引用catch块）的能力是返回值的好处。
Java对“真正的例外”的定义比C ++更广泛。C ++程序员比Java程序员更想查看函数的返回值，因此在Java中，“真正的例外”可能意味着“由于该函数的结果，我不能返回非null对象”。在C ++中，它更可能表示“我非常怀疑我的调用者是否可以继续”。因此，如果Java流无法读取文件，则会抛出该异常，而C ++流（默认情况下）将返回一个指示错误的值。但是，在所有情况下，这都取决于您愿意强迫调用者编写什么代码。因此，这的确是一种编码风格的问题：您必须达成共识，代码应该是什么样子，以及要针对多少“异常安全性”编写多少“错误检查”代码
所有语言之间的广泛共识似乎是，就错误的可恢复性而言，这是最好的做法（因为不可恢复的错误导致没有异常的代码，但仍然需要检查并返回自己的代码，使用错误返回的代码中的错误）。因此人们开始期望“我调用的此函数引发异常”的意思是“我无法继续”，而不仅仅是“它不能继续”。这不是异常情况所固有的，它只是一个自定义，但像任何良好的编程习惯一样，它是一个聪明的人提倡的自定义，他们以另一种方式尝试了这种方法，但并不喜欢结果。因此，我个人认为确实是“非常例外”，除非有关情况使例外特别有吸引力。
顺便说一句，除了推理代码状态外，还涉及性能。现在，使用您有权关心性能的语言，异常通常很便宜。它们可以比多个级别的速度更快，“哦，结果是错误的，那么我也最好退出自己的错误”。在糟糕的过去，人们确实担心会抛出异常，捕捉异常并继续进行下一件事情，这会使您的工作变得如此缓慢以至无用。因此，在这种情况下，“真的非常”意味着“情况非常糟糕，以至于可怕的表现不再重要”。情况不再如此（尽管紧密循环中的异常仍然很明显），并希望指出为什么“真正例外”的定义需要灵活。
new）和标准库都抛出了异常，所以我不明白在代码中不使用异常如何使您不必编写异常安全的代码。
确实没有达成共识。整个问题在某种程度上是主观的，因为通常由语言本身的标准库中的现有实践建议抛出异常的“适当性”。C ++标准库抛出异常的频率比说Java标准库要少得多，Java标准库几乎总是喜欢使用异常，即使对于预期的错误（例如无效的用户输入（例如Scanner.nextInt））也是如此。我认为，这将极大地影响开发人员对何时引发异常的意见。
作为一名C ++程序员，我个人更喜欢在非常“异常”的情况下保留异常，例如，内存不足，磁盘空间不足，启示录发生等。但是我不坚持认为这是绝对正确的方法东西。
我认为，应该很少使用例外。但。
并非所有团队和项目都准备好使用异常。异常的使用要求程序员具有很高的资格，需要特殊技术，并且缺少大量的传统的非异常安全代码。如果您拥有庞大的旧代码库，那么它几乎总是不安全的。我确定您不想重写它。
如果要广泛使用异常，则：
另一方面，在具有强大团队的新项目中使用异常可以使代码更清洁，更易于维护甚至更快：
编辑11/20/2009：
我刚刚读了这篇有关改善托管代码性能的MSDN文章，这一部分让我想起了这个问题：
引发异常的性能代价是巨大的。尽管建议使用结构化异常处理方式来处理错误情况，但请确保仅在发生错误情况的特殊情况下才使用例外。不要为常规控制流使用异常。
当然，这仅适用于.NET，它还专门针对那些正在开发高性能应用程序的人（例如我本人）。所以这显然不是普遍真理。尽管如此，我们还有很多.NET开发人员，所以我觉得值得一提。
编辑：
好吧，首先，让我们直接讲一件事：我无意在性能问题上与任何人打架。总的来说，实际上，我倾向于同意那些认为过早优化是一种罪过的人。但是，我只想指出两点：
张贴者要求在传统观念基础上提出客观理由，即应该谨慎使用例外。我们可以讨论我们想要的可读性和适当的设计；但是这些都是主观的问题，人们随时准备在任何一方争论。我认为发布者已经意识到了这一点。事实是，使用异常来控制程序流通常是一种低效的处理方式。不，并非总是如此，但经常如此。这就是为什么谨慎使用例外情况是合理的建议的原因，就像少量食用红肉或喝红酒的良好建议一样。
在没有充分理由的情况下进行优化与编写高效代码之间存在区别。必然的结果是，编写健壮的东西（如果没有进行优化）和纯粹无效的东西是有区别的。有时候，我认为当人们争论诸如异常处理之类的事情时，他们实际上只是在互相交谈，因为他们正在讨论根本不同的事情。
为了说明我的观点，请考虑以下C＃代码示例。
这就是所谓的异常滥用的一个例子。
int value = -1;
string input = GetInput();
bool inputChecksOut = false;
while (!inputChecksOut) {
try {
value = int.Parse(input);
inputChecksOut = true;
} catch (FormatException) {
input = GetInput();
}
}
对我来说，这段代码很荒谬。当然可以。没有人对此争论。但这应该是这样的：
int value = -1;
string input = GetInput();
while (!int.TryParse(input, out value)) {
input = GetInput();
}
我认为这种情况实际上非常普遍。对于许多人来说，这当然似乎更“可接受”，因为它处理文件I / O：
string text = null;
string path = GetInput();
bool inputChecksOut = false;
while (!inputChecksOut) {
try {
using (FileStream fs = new FileStream(path, FileMode.Open)) {
using (StreamReader sr = new StreamReader(fs)) {
text = sr.ReadToEnd();
}
}
inputChecksOut = true;
} catch (FileNotFoundException) {
path = GetInput();
}
}
这似乎足够合理，对吧？我们正在尝试打开文件；如果不存在，我们将捕获该异常并尝试打开其他文件...这是怎么回事？
真的没什么。但是考虑一下这种替代方案，它不会引发任何异常：
string text = null;
string path = GetInput();
while (!File.Exists(path)) path = GetInput();
using (FileStream fs = new FileStream(path, FileMode.Open)) {
using (StreamReader sr = new StreamReader(fs)) {
text = sr.ReadToEnd();
}
}
当然，如果这两种方法的性能实际上相同，那么这实际上将纯粹是一个理论问题。因此，让我们看一下。对于第一个代码示例，我列出了10000个随机字符串的列表，其中没有一个表示正确的整数，然后在最后添加一个有效的整数字符串。使用以上两种方法，这些都是我的结果：
使用try/catch封锁：25.455秒
使用int.TryParse：1.637毫秒
对于第二个示例，我基本上执行了相同的操作：列出了10000个随机字符串的列表，这些都不是有效路径，然后在最后添加一个有效路径。结果是：
使用try/catch阻止：29.989秒
使用File.Exists：22.820毫秒
许多人对此表示反对：“是的，抛出并捕获10,000个异常是极其不现实的；这会夸大结果。” 当然可以。用户不会注意到抛出一个异常和自行处理错误输入之间的区别。事实仍然是，在这两种情况下，使用异常的速度比可读性高的替代方法慢1000到10,000倍以上（如果不是更多的话）。
这就是为什么我包含GetNine()以下方法的示例。不是说它的速度慢得令人无法忍受或令人无法接受。这是它的速度慢于应有的速度……没有充分的理由。
同样，这些只是两个示例。中当然会有时候使用异常的性能损失并不严重这（帕维尔的权利;毕竟，它不依赖于实现）。我要说的是：伙计们，让我们面对现实-在上述情况下，抛出和捕获异常类似于GetNine()；这只是做某事的效率低下，可以轻松地做得更好。
您要提出一个基本原理，就好像这是每个人都不知道为什么而跳入潮流的情况之一。但实际上答案很明显，我想您已经知道了。异常处理具有可怕的性能。
好的，也许对您的特定业务场景来说很好，但是相对而言，抛出/捕获异常会带来很多不必要的开销。您知道，我知道：大多数时候，如果您使用异常来控制程序流，您只是在编写慢速代码。
您可能还会问：为什么这段代码不好？
private int GetNine() {
for (int i = 0; i < 10; i++) {
if (i == 9) return i;
}
}
我敢打赌，如果您对此功能进行了概要分析，您会发现它对于典型的业务应用程序的执行速度相当快。这并没有改变这样一个事实，那就是这是一种效率低下的方法，无法完成可以做得更好的事情。
这就是人们谈论异常“滥用”时的意思。
GetNine它的工作很好。我的观点是没有理由使用它。这并不是完成工作的“快速而简单”的方法，而更“正确”的方法将需要更多的精力。以我的经验，通常情况下，“正确”的方法实际上会花费更少的精力，或者差不多。无论如何，对我而言，性能是不鼓励使用左右异常的唯一客观原因。至于性能损失是否被“严重高估”，这实际上是主观的。
不是很少应该使用例外。只是它们只应在特殊情况下抛出。例如，如果用户输入了错误的密码，那不是例外。
原因很简单：异常会突然退出函数，并沿堆栈向上传播到一个catch块。此过程在计算上非常昂贵：C ++构建其异常系统时，对“常规”函数调用的开销很小，因此，当引发异常时，它必须做大量工作才能找到要去的地方。而且，由于每一行代码都可能引发异常。如果我们有一些f经常引发异常的函数，那么我们现在必须注意在每次调用时都使用try/catch块f。这是一个非常糟糕的接口/实现耦合。
我对错误进行处理的方法是存在三种基本错误类型：
assert如此）。通常，这些情况表明代码中的某些内容已损坏，您实际上无法信任任何其他正确的内容-可能存在猖ramp的内存损坏。您的船正在下沉，下车。解释一下，例外是当您遇到问题时可以解决的，但无法在发现问题的地方解决。您无法处理的问题应该简单地杀死程序；您可以立即处理的问题应该得到处理。
我在这里阅读了一些答案。我仍然对所有这些困惑感到惊讶。我非常不同意所有这些exceptions == spagetty代码。混乱是指有些人不欣赏C ++异常处理。我不确定如何了解C ++异常处理-但我在几分钟内就了解了其中的含义。那是在1996年左右，当时我在使用OS / 2的borland C ++编译器。我从来没有什么问题可以决定何时使用异常。我通常将容易犯错的撤消操作包装到C ++类中。此类撤消操作包括：
比功能包装还多。将系统调用（不属于前一类）包装到C ++中。例如从文件读/写。如果失败，将引发异常，其中包含有关错误的完整信息。
然后是捕获/抛出异常，以向故障添加更多信息。
总体而言，C ++异常处理将导致更清晰的代码。大大减少了代码量。最终，人们可以使用构造函数来分配易变的资源，并且在发生此类故障后仍可以保持无损坏的环境。
可以将这样的类链接为复杂的类。一旦执行了某个成员/基础对象的构造函数，就可以依靠该对象（之前执行）的所有其他构造函数成功执行。
与传统构造（循环，if，函数等）相比，异常是一种非常不寻常的流控制方法。常规控制流构造（循环，if，函数调用等）可以处理所有正常情况。如果发现例行事件会导致异常，那么也许您需要考虑代码的结构。
但是，某些类型的错误无法通过常规构造轻松解决。灾难性故障（例如资源分配故障）可以在较低的级别上检测到，但可能无法在此处进行处理，因此，简单的if语句不足。这些类型的故障通常需要在更高级别上进行处理（例如，保存文件，记录错误，退出）。试图通过传统方法（如返回值）报告这样的错误既繁琐又容易出错。此外，它将开销投入到中级API层中，以处理这种奇怪的异常故障。开销分散了这些API的客户端，并要求它们担心超出其控制范围的问题。异常提供了一种对大错误进行非本地处理的方法
如果客户端ParseInt使用字符串进行调用，并且该字符串不包含整数，则直接调用者可能会关心该错误并知道如何处理。因此，您可以将ParseInt设计为返回诸如此类的失败代码。
另一方面，如果ParseInt由于由于内存碎片严重而无法分配缓冲区而失败，则调用者将不知道该如何处理。它将不得不冒这个不寻常的错误，直到处理这些基本故障的某个层次。这会给介于两者之间的每个人增加负担（因为他们必须在自己的API中容纳错误传递机制）。使用异常可以跳过这些层（同时仍确保进行必要的清理）。
在编写低级代码时，可能很难决定何时使用传统方法以及何时引发异常。低级代码必须做出决定（是否抛出）。但是，真正了解期望值和例外情况的是更高级别的代码。
parseInt实际上确实会引发异常。因此，我想说的是，有关引发异常的适当性的意见高度依赖于其选择的开发语言的标准库中的现有做法。
在C ++中有几个原因。
首先，通常很难看到异常的来源（因为它们几乎可以从任何东西中抛出），因此catch块是COME FROM语句的一部分。它比GO TO更糟糕，因为在GO TO中，您知道您来自哪里（该语句，而不是一些随机函数调用）以及您要到达的位置（标签）。它们基本上是C的setjmp（）和longjmp（）的潜在资源安全版本，没有人愿意使用它们。
其次，C ++没有内置垃圾回收，因此拥有资源的C ++类在其析构函数中将其清除。因此，在C ++异常处理中，系统必须在范围内运行所有析构函数。在没有GC且没有真正的构造函数的语言（如Java）中，抛出异常的负担要轻得多。
第三，C ++社区，包括Bjarne Stroustrup和标准委员会以及各种编译器作者，一直在假设例外应该是例外。一般来说，与语言文化相抵触是不值得的。这些实现基于例外将很少发生的假设。更好的书将例外视为例外。好的源代码很少使用例外。优秀的C ++开发人员将异常视为例外。与此相反，您需要一个很好的理由，而我所看到的所有理由都是为了使其与众不同。
finally块与C ++析构函数在实现开销方面没有任何不同。
finally不能保证运行Java块-当然可以。我对finalize()不能保证运行的Java方法感到困惑。
这是一个使用异常作为控制流的错误示例：
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;
}
第二个示例显然需要一些重构（例如使用设计模式策略），但是很好地说明了异常并不意味着控制流。
异常还会带来一些性能损失，但是性能问题应遵循以下规则：“过早的优化是万恶之源”
incomeType。
at()？就是说，任何人new都可以扔，所以……
我要说的是，异常是一种以安全的方式使您脱离当前上下文（从最简单的意义上来说，脱离当前堆栈框架，但不止于此）的机制。这是结构化编程最接近goto的东西。要按预期使用异常的方式使用异常，您必须遇到一种情况，即您无法继续您现在正在做的事情，并且无法在当下的时刻处理它。因此，例如，当用户密码错误时，可以通过返回false继续操作。但是，如果UI子系统报告它甚至无法提示用户，则仅返回“登录失败”将是错误的。当前的代码级别根本不知道该怎么办。因此，它使用异常机制将责任委派给可能知道该做什么的人。
合法案例引发异常：
非法案例：
当我想将应用程序的流程分解到一定程度时，会使用异常。这是该异常的catch（...）所在的位置。例如，很常见，我们必须处理大量项目，并且每个项目都应独立于其他项目进行处理。因此，处理项目的循环具有一个try ... catch块，并且如果在项目处理过程中引发了某些异常，则该项目的所有内容都会回滚，记录错误，并处理下一个项目。生活仍在继续。
我认为您应该对不存在的文件，无效的表达式以及类似的东西使用异常。 如果有简单/便宜的替代方法，则不应在范围测试/数据类型测试/文件存在/其他情况下使用异常。 如果有简便/廉价的替代方案，则不应在范围测试/数据类型测试/文件存在/其他情况下使用异常，因为这种逻辑会使代码难以理解：
RecordIterator<MyObject> ri = createRecordIterator();
try {
MyObject myobject = ri.next();
} catch(NoSuchElement exception) {
// Object doesn't exist, will create it
}
这样会更好：
RecordIterator<MyObject> ri = createRecordIterator();
if (ri.hasNext()) {
// It exists!
MyObject myobject = ri.next();
} else {
// Object doesn't exist, will create it
}
添加到答案的评论：
也许我的示例不是很好-ri.next（）在第二个示例中不应引发异常，如果发生异常，则确实存在一些异常，应在其他地方采取其他措施。当大量使用示例1时，开发人员将捕获通用异常而不是特定异常，并假定该异常是由于他们所期望的错误，但也可能是由于其他原因。最后，这导致实际异常被忽略，因为异常成为应用程序流的一部分，而不是应用程序流的一部分。
对此的评论可能会比我的回答本身更多。
try块内累积，然后您就无法再确定该catch块确实在捕获您认为正在捕获的东西了吗？虽然很难以相同的方式滥用if / then / else方法，因为您一次只能测试一件事，而不能一次测试一组事情，因此异常方法会导致代码更加脆弱。如果是这样，请在您的答案中进行讨论，我会很乐意+1，因为我认为代码脆弱性是善意的原因。
我认为“很少使用”不是正确的句子。我希望“仅在特殊情况下才扔”。
许多人已经解释了为什么在正常情况下不应使用异常。异常具有处理错误的权利，并且仅具有处理错误的权利。
我将重点放在另一点：
另一件事是性能问题。编译器为使它们快速运行而竭尽全力。我不确定现在的确切状态，但是当您将异常用于控制流时，您会遇到另一个麻烦：您的程序将变慢！
原因是，异常不仅是非常强大的goto语句，而且它们还必须释放堆栈中所有离开的帧。因此，隐式地，堆栈上的对象也必须被解构，依此类推。因此，如果不知道这一点，那么抛出一个异常确实会涉及到很多机制。处理器将不得不做很多事情。
因此，您最终将在不知不觉中优雅地刻录处理器。
因此：仅在例外情况下使用例外-含义：当发生真正的错误时！
std::terminate()，您仍然必须销毁。
如果出现以下情况，我将使用例外：
如果错误可以从中恢复（用户输入的是“ apple”而不是数字），则可以恢复（再次询问输入，更改为默认值，等等）。
如果无法从本地恢复错误，但应用程序可以继续（用户尝试打开文件，但该文件不存在），则错误代码是适当的。
如果无法从本地恢复错误，并且应用程序无法恢复而无法继续运行（您的内存/磁盘空间不足等），那么采取异常处理是正确的方法。
谁说应该保守使用？只是永远不要将异常用于流控制，仅此而已。谁在乎已经抛出异常的代价？
我的两分钱：
我喜欢使用异常，因为它使我可以编程，好像不会发生任何错误。因此，我的代码保持可读性，不会因各种错误处理而分散。当然，错误处理（异常处理）被移到末尾（catch块），或者被认为是调用级别的责任。
对我来说，一个很好的例子是文件处理或数据库处理。假设一切正常，然后在最后或发生某些异常时关闭文件。或在发生异常时回滚您的事务。
例外的问题是，它很快变得非常冗长。虽然它旨在使您的代码保持高度可读性，并且只专注于正常的事物流，但是如果使用得当，几乎每个函数调用都需要包装在try / catch块中，这会破坏目的。
对于前面提到的ParseInt，我喜欢例外的想法。只需返回值即可。如果参数不可解析，则引发异常。一方面，它使您的代码更整洁。在呼叫级别，您需要执行以下操作
try
{
b = ParseInt(some_read_string);
}
catch (ParseIntException &e)
{
// use some default value instead
b = 0;
}
代码是干净的。当我像这样散布所有的ParseInt时，我使包装函数处理异常并返回默认值。例如
int ParseIntWithDefault(String stringToConvert, int default_value=0)
{
int result = default_value;
try
{
result = ParseInt(stringToConvert);
}
catch (ParseIntException &e) {}
return result;
}
因此可以得出结论：在整个讨论过程中，我错过了一个事实，那就是异常使我可以使我的代码更容易/更具可读性，因为我可以更多地忽略错误条件。问题：
因此，有时很难找到一个良好的平衡。
很抱歉，答案是“由于某种原因，它们被称为例外”。这种解释是“经验法则”。您无法给出应该使用或不应该使用异常的完整情况集，因为针对一个问题域的致命异常（英语定义）是针对不同问题域的正常操作过程。经验法则不能盲目遵循。相反，它们旨在指导您对解决方案进行调查。“将它们称为异常是有原因的”告诉您，应提前确定调用者可以处理的正常错误以及在没有特殊编码（捕获块）的情况下调用者无法处理的异常情况。
几乎每个编程规则实际上都是一个准则，上面写着“除非有充分的理由，否则请不要这样做”：“切勿使用goto”，“避免使用全局变量”，“正则表达式将问题数量预先增加一个”等。例外也不例外。...