在验证数据时抛出异常是好还是坏？

Question

在验证数据时,我养成了做以下事情的习惯

*注意:我每次检查都没有真正的布尔值.这只是一个例子.

*另一个注意事项:测试期间的任何错误处理都已正确完成.try-catch中抛出的唯一异常是我自己的.

try {
  if (validCheckOne = false) {
    throw new Exception("Check one is bad");
  }
  if (validCheckTwo = false) {
    throw new Exception("Failed because of check2");
  }
  if(validCheckTen = false) {
    throw new Exception("Yet another failure on your part: check10.");
  }
} catch(Exception e) {
  MessageBox.Show("Your stupid data is wrong! See for yourself: " + e.Message);
}

这是不好的做法吗？抛出异常会减慢程序的执行速度还是不可取的？

Answer 1

就个人而言,我喜欢为业务规则验证抛出异常(而不是用户输入验证),因为它会强制在上游处理问题.如果我的业务对象返回了某种验证结果,则调用者可以忽略它.如果你愿意,叫我牛仔:)

这里的每个人都在重复"例外情况适用于特殊情况"这一短语,但实际上并没有理解为什么在特殊情况下使用它们是不好的.我需要更多.抛出异常的性能是否真的那么糟糕？有没有可用的基准？

Answer 2

我将在这里重复咒语:应该在特殊情况下抛出异常.无效的输入数据确实不是那么特别.

Answer 3

我支持MusiGenesis的回答.

另外...

抛出异常的表现是一千条指令.与最终用户时间相比,它没什么,但在内部代码中它很慢.

另一个问题是,使用例外,您的验证仅限于报告第一次失败(并且您将不得不在下次再次完成所有操作以查找下一次失败).

Answer 4

除了经常重复的声明"例外是针对特殊情况"之外,这里还有一个额外的澄清规则:

如果用户造成它,那也不例外.

例外情况是系统方面的事情(服务器停机,资源不可用),而不是用户做奇怪的事情,因为所有用户都做奇怪的事情.

Answer 5

在标题中,您将其称为"验证"数据.这可能发生在几个层面上.在您检查用户输入数据的GUI中(接近),您应该期待错误并有办法报告错误.在这种情况下,例外是不恰当的.

但是数据验证也可以发生在其他边界,比如业务规则类之间.在那里,数据中的错误是不常见和意外的.当你发现一个时,你应该扔掉.

Answer 6

这取决于 - 如果您希望数据存在并且没有数据是意外的,那么抛出异常就可以了.抛出异常非常昂贵(缓慢)但是处理意外情况的最佳方法.