在.NET中使用try-catch进行流量控制是"糟糕的"吗?

dno*_*ord 6 c# try-catch

我刚刚在一个项目中找到:

try
{
    myLabel.Text = school.SchoolName;
}
catch
{
    myPanel.Visible = false;
}
Run Code Online (Sandbox Code Playgroud)

我想和开发人员谈谈,而不是写这个,说发生null异常(因为school理论上可能是null,不是myLabel)会使计算机发出三次蜂鸣声并睡两秒钟.但是,我想知道我是否错过了关于这一点的规则.显然,这不是try/catch的预期用途,但这是不好的,因为它因性能考虑而无视意图或不好?我觉得这很糟糕,但我想说的不仅仅是"那真的很糟糕".

Max*_*ing 20

您不应该仅仅因为设计不好而对控制流使用异常.这没有意义.例外是针对特殊情况,而不是正常流量.性能可能不会在这种情况下的一个问题,因为在现代硬件上最先进的应用程序,你可以整天抛出异常,并且用户不会注意到性能损失.但是,如果这是一个处理大量数据或执行大量工作的高性能应用程序,那么是的,性能将是一个问题.


Mat*_*ith 9

在我看来,这很糟糕,因为if语句可以更加清晰:

if (school != null) {
    myLabel.Text = school.SchoolName;
}
else {
    myPanel.Visible = false;
}
Run Code Online (Sandbox Code Playgroud)

这肯定会避免不必要地使用异常处理,并使代码的含义非常明显.


Sta*_* R. 8

我认为这很糟糕,因为它针对一个异常编码,它也会继承不必要的开销.只有在以特定方式处理异常时才应捕获异常.

应该专门针对您无法预测的例外情况捕获异常,在这种情况下,它是一个简单的检查,看看学校是否可以为null,实际上预计学校可能为空(因为标签没有设置).如果school是null并且它不应该是它应该抛出自己的ArgumentNullException.