在Validate()方法上抛出异常或更好地返回bool值是一个好习惯吗？

Question

是否建议从验证方法中抛出异常,例如:

ValidateDates();
ValidateCargoDetails();

除此之外:是否经常使用强大的验证设计模式？

Answer 1

我建议返回一个包含ValidationFailures的ValidationResult对象.您不应该将异常用作逻辑编码的一部分.例外是例外

@Peter Lawrey - 根据我的经验,输入无效数据的用户是规则,而不是例外. (12认同)
@PeterLawrey:在决定是否应该是一个例外时,最好的问题是"*即时调用代码*是否应该处理这个条件？" 如果不是,则抛出异常.代码调用验证例程的事实非常强烈地表明代码已准备好处理失败的可能性.这不是100%的含义 - 调用者可能没有准备做除了失败以外的任何事情,但可能已经调用例程避免执行稍后会失败的操作 - 但是它会倾向于使用错误返回码vs例外. (7认同)
验证失败不应该是特殊的吗？ (5认同)
@Jarrett,我认为很多都取决于你在验证什么,以及你需要采取什么行动来解决失败.例外对用户没用,他们希望友好地描述他们应该做什么.但是,如果您需要停止处理,则异常非常有用,并且可以忽略的友好消息是危险的. (4认同)
我真不知道这个规定是从哪里来的。如果操作失败，无论出于何种原因，对我来说都是例外。我的意思是，我们有诸如无效参数异常之类的情况。无效数据异常有何不同？在 REST 环境中，我认为返回 400 错误并将验证结果嵌入 JSON 更有意义。这在 JavaScript 中不被视为异常吗？它将触发您的 AJAX 错误处理程序。通过使用 ValidationResult，您将被迫使用该类型污染所有公共方法，无论它们是否实际使用验证。 (2认同)

Answer 2

我通常visitor pattern用于验证输入; 将所有错误累积到列表或其他内容以显示用户.逻辑就像是,检查列表中的验证错误,如果找到,通知用户,否则很好.

IMO,验证错误并不是特例,因此它不应该像一个人那样处理.

Answer 3

我会说这完全取决于你在做什么/如何进行验证.但是在一天结束时,开发人员总是可以选择忽略返回的结果(这是他们的问题),他们不能忽略异常而不编写显式代码来执行此操作.

Answer 4

不得使用抛出异常来控制应用程序的流程。顾名思义，它发生在特殊情况下，而验证通常会失败。它们也很昂贵并且会影响性能。

我会返回一个布尔值和一个字符串 for reason。

@BornToCode 使用“out”是一个糟糕的主意（除非你真的必须这样做——我已经好几年没用过了）。C# 应该是一种面向对象的语言，所以创建一个类。 (3认同)

Answer 5

在很大程度上取决于异常验证失败对正确性的重要性。

如果您的验证失败发生时罕见且严重或致命，我会使用异常甚至断言错误。大多数解析器使用异常，这些表示无法继续处理。

如果您的验证失败在正常操作下预期失败并且不表明您无法继续处理，我建议使用访问者模式或返回问题列表（可以为空）

@Rumel BufferedReader.readLine() 在没有更多数据时返回 `null`，这是预期的结果，但是如果出现错误，则会引发异常。 (3认同)