为什么不将异常用作常规控制流? [英] 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).
但是，从我的恶毒天性来看，我会通过将这种行为扩展为覆盖的" 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.
}
}
当然，if可以解决这个问题，但是事实仍然是，我只是看不到为什么不能使用异常(从逻辑上讲，我可以看到，当性能是在某些情况下会出现异常的问题时，应该避免).
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:
- 清除
- 兑现您的方法合同
射杀我.
推荐答案
您是否曾经尝试过在正常操作过程中调试每秒产生五个异常的程序?
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屋！
