exception - 为什么不使用异常作为常规控制流？

Question

为了避免我在 Google 上搜索到的所有标准答案，我将提供一个大家可以随意攻击的示例。

C# 和 Java(以及太多其他)有很多类型，但我根本不喜欢一些“溢出”行为(例如 type.MaxValue + type.SmallestValue == type.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 可以同样简单地解决这个问题，但事实仍然是，我只是不明白为什么不能使用异常(从逻辑上讲，也就是说，我可以看到，当性能成为一个问题时，在某些情况下异常应避免)。

我认为在很多情况下它们比 if 结构更清晰，并且不会破坏该方法正在制定的任何契约。

恕我直言，每个人似乎都有的“永远不要将它们用于常规程序流程”的 react 并不是那么不充分，因为这种 react 的强度可以证明是合理的。

还是我错了？

我读过其他帖子，处理各种特殊情况，但我的观点是，如果你们都是:

1. 清除
2. 遵守您的方法的契约(Contract)

向我开枪。

Answer 1

您是否曾经尝试过调试在正常操作过程中每秒引发五个异常的程序？

我有。

该程序相当复杂(它是一个分布式计算服务器)，程序一侧的轻微修改很容易在完全不同的地方破坏某些东西。

我希望我可以启动程序并等待异常发生，但是在启动过程中在正常操作过程中出现了大约 200 个异常

我的观点:如果您在正常情况下使用异常，您如何定位异常(即异常al)情况？

当然，还有其他充分的理由不要过多使用异常，尤其是性能方面