为了避免所有我可以在谷歌上搜索到的标准答案，我将提供一个你们都可以随意攻击的例子。
c#和Java(以及其他很多语言)有很多类型，有些“溢出”行为我一点也不喜欢(例如type。MaxValue +类型。SmallestValue ==类型。MinValue，例如int。MaxValue + 1 = int.MinValue)。
但是，鉴于我的邪恶本性，我将通过将此行为扩展为重写DateTime类型来对这种伤害进行侮辱。(我知道DateTime在. net中是密封的，但为了这个例子，我使用了一种与c#完全相似的伪语言，除了DateTime没有密封之外)。
被覆盖的Add方法:
/// <summary>
/// Increments this date with a timespan, but loops when
/// the maximum value for datetime is exceeded.
/// </summary>
/// <param name="ts">The timespan to (try to) add</param>
/// <returns>The Date, incremented with the given timespan.
/// If DateTime.MaxValue is exceeded, the sum wil 'overflow' and
/// continue from DateTime.MinValue.
/// </returns>
public DateTime override Add(TimeSpan ts)
{
try
{
return base.Add(ts);
}
catch (ArgumentOutOfRangeException nb)
{
// calculate how much the MaxValue is exceeded
// regular program flow
TimeSpan saldo = ts - (base.MaxValue - this);
return DateTime.MinValue.Add(saldo)
}
catch(Exception anyOther)
{
// 'real' exception handling.
}
}
当然，如果可以很容易地解决这个问题，但事实仍然是，我不明白为什么不能使用异常(从逻辑上讲，我可以看到，当性能是一个问题时，在某些情况下应该避免异常)。
我认为在许多情况下，它们比if结构更清晰，并且不会破坏方法所做的任何契约。
恕我直言，“永远不要在常规程序流程中使用它们”的反应似乎并不是每个人都有，因为这种反应的力量可以证明。
还是我说错了?
我读过其他的帖子，处理各种特殊情况，但我的观点是，如果你们都是:
清晰的
尊重你的方法
拍我。
正如其他人已经多次提到的，最小惊讶原则将禁止您仅为控制流的目的而过度使用异常。另一方面，没有任何规则是100%正确的，总有一些情况下，异常是“合适的工具”——就像goto本身，顺便说一下，它在Java等语言中以break和continue的形式发布，这通常是跳出大量嵌套循环的完美方式，而这种循环并不总是可以避免的。
下面的博文解释了一个相当复杂但也相当有趣的非本地ControlFlowException的用例:
http://blog.jooq.org/2013/04/28/rare-uses-of-a-controlflowexception
它解释了在jOOQ (Java的SQL抽象库)内部，当满足某些“罕见”条件时，如何偶尔使用这种异常来提前中止SQL呈现过程。
这种条件的例子有:
Too many bind values are encountered. Some databases do not support arbitrary numbers of bind values in their SQL statements (SQLite: 999, Ingres 10.1.0: 1024, Sybase ASE 15.5: 2000, SQL Server 2008: 2100). In those cases, jOOQ aborts the SQL rendering phase and re-renders the SQL statement with inlined bind values. Example:
// Pseudo-code attaching a "handler" that will
// abort query rendering once the maximum number
// of bind values was exceeded:
context.attachBindValueCounter();
String sql;
try {
// In most cases, this will succeed:
sql = query.render();
}
catch (ReRenderWithInlinedVariables e) {
sql = query.renderWithInlinedBindValues();
}
If we explicitly extracted the bind values from the query AST to count them every time, we'd waste valuable CPU cycles for those 99.9% of the queries that don't suffer from this problem.
Some logic is available only indirectly via an API that we want to execute only "partially". The UpdatableRecord.store() method generates an INSERT or UPDATE statement, depending on the Record's internal flags. From the "outside", we don't know what kind of logic is contained in store() (e.g. optimistic locking, event listener handling, etc.) so we don't want to repeat that logic when we store several records in a batch statement, where we'd like to have store() only generate the SQL statement, not actually execute it. Example:
// Pseudo-code attaching a "handler" that will
// prevent query execution and throw exceptions
// instead:
context.attachQueryCollector();
// Collect the SQL for every store operation
for (int i = 0; i < records.length; i++) {
try {
records[i].store();
}
// The attached handler will result in this
// exception being thrown rather than actually
// storing records to the database
catch (QueryCollectorException e) {
// The exception is thrown after the rendered
// SQL statement is available
queries.add(e.query());
}
}
If we had externalised the store() logic into "re-usable" API that can be customised to optionally not execute the SQL, we'd be looking into creating a rather hard to maintain, hardly re-usable API.
结论
从本质上讲，我们对这些非本地goto的使用就像[Mason Wheeler][5]在他的回答中所说的那样:
“我刚刚遇到了一种情况，此时我无法正确处理它，因为我没有足够的上下文来处理它，但调用我的例程(或调用堆栈的更上层)应该知道如何处理它。”
controlflowexception的两种用法与它们的替代方法相比都很容易实现，允许我们重用广泛的逻辑，而无需从相关的内部重构它。
但是对于未来的维护者来说，这种感觉还是有点令人惊讶。代码感觉相当微妙，虽然在这种情况下这是正确的选择，但我们总是不喜欢在本地控制流中使用异常，因为在本地控制流中很容易避免使用普通的if - else分支。
我的经验法则是:
如果您可以做任何事情来从错误中恢复，捕获异常
如果这个错误是很常见的(例如。用户尝试使用错误的密码登录)，使用returnvalues
如果您不能做任何事情来从错误中恢复，那么就让它不被捕获(或者在主捕获器中捕获它，以半优雅地关闭应用程序)
我认为异常的问题纯粹是从语法的角度来看的(我非常确定性能开销是最小的)。我不喜欢到处都是尝试块。
举个例子:
try
{
DoSomeMethod(); //Can throw Exception1
DoSomeOtherMethod(); //Can throw Exception1 and Exception2
}
catch(Exception1)
{
//Okay something messed up, but is it SomeMethod or SomeOtherMethod?
}
. .另一个例子是，当你需要使用工厂将一些东西赋值给一个句柄时，该工厂可能会抛出异常:
Class1 myInstance;
try
{
myInstance = Class1Factory.Build();
}
catch(SomeException)
{
// Couldn't instantiate class, do something else..
}
myInstance.BestMethodEver(); // Will throw a compile-time error, saying that myInstance is uninitalized, which it potentially is.. :(
就我个人而言，我认为你应该为罕见的错误条件(内存不足等)保留异常，而使用returnvalues(值类，结构或枚举)来进行错误检查。
希望我正确理解了你的问题:)
Josh Bloch在《Effective Java》中广泛地讨论了这个主题。他的建议很有启发性，也适用于。net(细节除外)。
特别地，例外应用于特殊情况。原因主要与可用性有关。对于一个给定的方法，要最大限度地使用，它的输入和输出条件应该受到最大限度的约束。
例如，第二种方法比第一种方法更容易使用:
/**
* Adds two positive numbers.
*
* @param addend1 greater than zero
* @param addend2 greater than zero
* @throws AdditionException if addend1 or addend2 is less than or equal to zero
*/
int addPositiveNumbers(int addend1, int addend2) throws AdditionException{
if( addend1 <= 0 ){
throw new AdditionException("addend1 is <= 0");
}
else if( addend2 <= 0 ){
throw new AdditionException("addend2 is <= 0");
}
return addend1 + addend2;
}
/**
* Adds two positive numbers.
*
* @param addend1 greater than zero
* @param addend2 greater than zero
*/
public int addPositiveNumbers(int addend1, int addend2) {
if( addend1 <= 0 ){
throw new IllegalArgumentException("addend1 is <= 0");
}
else if( addend2 <= 0 ){
throw new IllegalArgumentException("addend2 is <= 0");
}
return addend1 + addend2;
}
无论哪种情况，都需要检查以确保调用者正确地使用了您的API。但在第二种情况下，您需要它(隐式地)。如果用户没有读取javadoc，软异常仍然会被抛出，但是:
你不需要记录它。
你不需要测试它(取决于你的攻击性有多强
单元测试策略是)。
您不需要调用者处理三个用例。
最基本的一点是，异常不应该用作返回代码，很大程度上是因为你不仅让你的API变得复杂了，还让调用者的API变得复杂了。
当然，做正确的事情是有代价的。代价是每个人都需要理解他们需要阅读和遵循文档。希望是这样。
