一个方法应该忽略非法输入还是引发异常？

Question

如果方法检查它的输入并检测到非法输入，它应该怎么做：引发异常（或使用其他错误机制）或什么都不做/忽略错误的输入？

在Java中，如果将null-references作为参数给出，则HashTable类会抛出NullPointerException。这有时很烦人，但我认为它可能有优势，因为错误很早就被捕获了。其他一些方法忽略了非法输入，什么都不做。这不那么烦人，通常没有什么不好的事情发生，但可能有这种情况，那么这种行为会引起头痛 - 或者不是？

我不确定，哪种方式更好。所以我问你：你对这个问题有何看法？

Answer 1

绝对抛出异常。例外情况令人讨厌，迫使你做某事。

以这种方式思考，如果你的程序对输入错误没有任何作用，你应该如何让用户知道什么都没发生？为什么？此外，您需要多长时间来调试在错误条件下什么都不做的程序？

Answer 2

我认为取决于您正在处理的上下文或抽象层。最重要的是保持一致。如果您在该级别中抛出异常，请继续抛出异常。如果没有，请检查图层的行为方式并执行相同操作。

Answer 3

这在很大程度上取决于您正在开发的应用程序。

尽管非法输入进行士兵训练可能意味着该计划的输出不正确，对于计算药物剂量的应用来说，这将是一件非常糟糕的事情。另一方面，如果没有任何灾难性后果，那么什么都不做可能会没问题。

另一种选择是将非法输入更改为最接近的合法值（例如，如果整数的范围是0 - 100，并且您收到-10，则可以将其设置为0并继续处理）。 / p>

您应该尝试考虑如何处理您正在编写的特定方法中的错误以及错误处理将如何影响整个应用程序的可能后果。

Answer 4

假设这是一个公共方法，方法与调用此方法的方法之间的契约是什么？

如果您正在编写此方法，那么合同就是设计的一部分。你可以选择

• 以某种方式标记错误（自定义异常是一种选择，但不是唯一的选择）
• 在某些情况下纠正错误并继续
• 抛弃了错误的输入并继续进行，好像什么都没发生一样。

最后，它实际上取决于方法的作用以及对方法的期望。

您可以将Class替换为方法并使用相同的选项。

在某些情况下，您可能无法引发异常 - 即固件嵌入式微控制器。在这些情况下，您必须拥有一个专门用于处理错误输入并继续处理有效输入的流程。

干杯，

-R

Answer 5

快速失败：永远不要忽略错误的输入。你可能会隐藏问题并使它们很难找到。

有些人用Design by Contract（DBC）来推动这一点。

按照项目或公司中已使用的惯例进行操作 - 或立即进行定义。