为什么不使用异常作为常规控制流? [英] Why not use exceptions as regular flow of control?
问题描述
为了避免我可以在 Google 上搜索到的所有标准答案，我将提供一个大家可以随意攻击的示例.
To avoid all standard-answers I could have Googled on, I will provide an example you all can attack at will.
C# 和 Java(以及太多其他的)有很多类型的一些我根本不喜欢的溢出"行为(例如 type.MaxValue + type.SmallestValue == type.MinValue 例如:int.MaxValue + 1 == int.MinValue).
C# and Java (and too many others) have with plenty of types some of ‘overflow’ behaviour I don’t like at all (e.g type.MaxValue + type.SmallestValue == type.MinValue for example : int.MaxValue + 1 == int.MinValue).
但是，看到我的恶毒本性，我会通过将这种行为扩展到例如 Overridden DateTime 类型来增加对这种伤害的侮辱.(我知道 DateTime 在 .NET 中是密封的，但是为了这个例子，我使用了一种与 C# 完全一样的伪语言，除了 DateTime 没有密封的事实).
But, seen my vicious nature, I’ll add some insult to this injury by expanding this behaviour to, let’s say an Overridden DateTime type. (I know DateTime is sealed in .NET, but for the sake of this example, I’m using a pseudo language that is exactly like C#, except for the fact that DateTime isn’t sealed).
被覆盖的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.
}
}
当然，如果可以同样简单地解决这个问题，但事实仍然是我只是不明白为什么你不能使用异常(逻辑上也就是说，我可以看到当性能是一个问题时，在某些情况下异常应该避免).
Of course an if could solve this just as easy, but the fact remains that I just fail to see why you couldn’t use exceptions (logically that is, I can see that when performance is an issue that in certain cases exceptions should be avoided).
我认为在许多情况下，它们比 if 结构更清晰，并且不会破坏该方法正在制定的任何合同.
I think in many cases they are more clear than if-structures and don’t break any contract the method is making.
恕我直言，每个人似乎都有的永远不要将它们用于常规程序流程"的反应并没有像这种反应的强度所证明的那样充分.
IMHO the "Never use them for regular program flow" reaction everybody seems to have is not that well underbuild as the strength of that reaction can justify.
还是我弄错了?
我读过其他帖子，处理各种特殊情况，但我的观点是，如果你们都是这样，那就没有错:
I've read other posts, dealing with all kind of special cases, but my point is there's nothing wrong with it if you are both:
- 清除
- 尊重您的方法的合同
拍我.
推荐答案
你有没有试过调试一个在正常运行过程中每秒引发 5 个异常的程序?
Have you ever tried to debug a program raising five exceptions per second in the normal course of operation ?
我有.
该程序相当复杂(它是一个分布式计算服务器)，在程序的一侧稍作修改很容易在完全不同的地方破坏某些东西.
The program was quite complex (it was a distributed calculation server), and a slight modification at one side of the program could easily break something in a totally different place.
我希望我可以直接启动程序并等待异常发生，但是在启动期间大约有 200 个异常在正常操作过程中
I wish I could just have launched the program and wait for exceptions to occur, but there were around 200 exceptions during the start-up in the normal course of operations
我的观点:如果您在正常情况下使用异常，您如何定位异常(即异常al)情况?
My point : if you use exceptions for normal situations, how do you locate unusual (ie exceptional) situations ?
当然，还有其他充分的理由不要过多地使用异常，尤其是在性能方面
Of course, there are other strong reasons not to use exceptions too much, especially performance-wise
这篇关于为什么不使用异常作为常规控制流?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
