在.NET中使用try-catch进行流量控制是“不好的”吗？
我刚刚在一个项目中找到：
try { myLabel.Text = school.SchoolName; } catch { myPanel.Visible = false; } 我想与开发人员交谈，而不是写这个，说发生nullexception（因为school理论上可能是null，而不是myLabel ）实际上会使计算机发出三次哔声并睡两秒钟 。 但是，我想知道我是否错过了关于这一点的规则。 显然，这不是try / catch的预期用途，但这是不好的，因为它因性能考虑而无视意图或不好？ 我觉得这很糟糕，但我想说的不仅仅是“那真的很糟糕”。
您不应该仅仅因为设计不好而对控制流使用exception。 这没有意义。 例外是针对特殊情况，而不是正常流量。 在这种情况下，性能可能不会成为问题，因为对于现代硬件上的大多数现代应用程序，您可以整天抛出exception，用户不会注意到性能损失。 但是，如果这是一个处理大量数据或执行大量工作的高性能应用程序，那么是的，性能将是一个问题。
在我看来，这很糟糕，因为if语句可以更加清晰：
if (school != null) { myLabel.Text = school.SchoolName; } else { myPanel.Visible = false; }
这肯定会避免不必要地使用exception处理并使代码的含义非常明显。
我认为这很糟糕，因为它针对一个exception进行编码，并且还会inheritance不必要的开销。 只有在以特定方式处理exception时才应该捕获exception。
应该特别针对您无法预测的例外情况捕获exception，在这种情况下，它是一个简单的检查，看看学校是否可以为null，实际上预计学校可能为空（因为标签没有设置）。 如果school是null并且它不应该是它应该抛出自己的ArgumentNullException。
你是绝对正确的，这是不好的。 这很糟糕，因为它无视意图，因为它会伤害表现。
我意识到存在不同编程风格的空间，但就个人而言，我认为尽管这有效，但我可以看到代码试图做什么，它也会损害可读性和代码清晰度，使得维护更加困难程序员要遵循。 if语句在这里更合适。
抛出exception会对性能产生负面影响，请参阅http://msdn.microsoft.com/en-us/library/ms229009(VS.80).aspx
例外会导致运行时开销，但这里可能忽略不计。 在调试器中运行会有差异，但构建的二进制文件应该以几乎相同的速度运行。
告诉您的开发人员，任何黑猩猩都可以制作机器可以读取的代码。 好的代码是为人类而不是机器编写的。 如果你唯一担心的是nullexception，那么它可能是用户代码中的一个错误 – 没有人应该尝试将null赋给任何方式。 请改用Assert()语句。
我从不喜欢使用流量控制的exception。 例外是昂贵的，并且难以确定具有exception的程序的实际流程以便到达代码中的其他位置。 对我来说这就像使用GoTo。 这并不意味着你应该避免exception，而应该只是exception，这是程序中通常应该发生的exception。
我认为代码的一个更糟糕的部分是它甚至没有做任何exception的事情。 没有记录甚至解释为什么抛出exception。
看看这篇文章 “为什么不将例外用作常规控制流？”
我同意这里的每个人 – 这是一个可怕的想法。
在Java中有一些情况（我认为它们现在大部分已经消失，但在外部库中可能仍有一些情况），在这些情况下，您需要捕获某些“非exception”情况的exception。
通常，在编写库代码（实际上是任何类）时，请避免使用可能可以避免的ANYTHINGexception。 如果可能没有设置名称字段并且应该在write（）方法中导致exception，请确保添加一个isValid（）方法，以便您实际上没有捕获围绕写入的exception知道这儿存在一个问题。
（糟糕的Java代码附录）：这种“好”的编程风格实际上消除了Java中对已检查exception的任何需求，并且Java中检查的exception是Suck。