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

Question

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

在 Java 中，如果给定空引用作为参数，HashTable 类将抛出 NullPointerException。这有时很烦人，但我认为它可能有优势，因为错误会被及早发现。其他一些方法忽略非法输入，什么也不做。这不那么烦人，通常不会发生任何不好的事情，但可能会有一些情况，然后这种行为会导致头痛 - 或者不会？

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

Answer 1

肯定抛出异常。例外是故意令人讨厌的，以迫使您对它们做点什么。

这样想，如果你的程序对错误的输入什么都不做，你应该如何让用户知道什么都没发生，为什么？另外，调试一个在错误条件下不执行任何操作的程序需要多长时间？

Answer 2

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

Answer 3

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

尽管输入非法，但仍然坚持下去可能意味着程序的输出不正确，这对于计算药物剂量的应用程序来说是一件非常糟糕的事情。另一方面，如果不会导致任何灾难性的后果，那么什么都不做可能是可以的。

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

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

Answer 4

假设这是一个公共方法，那么该方法与调用该方法的人之间的约定是什么？

如果你正在编写这个方法，那么契约就是设计的一部分。你可以选择

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

最后，这实际上取决于该方法在做什么以及您对该方法有什么期望。

您可以用 Class 代替方法并具有相同的选项。

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

干杯，

-R

Answer 5

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

有些人通过合同设计(DBC)将这一点推得很远。

遵循已在您的项目或公司中使用的实践 - 或立即定义它们。