如果一个方法检查它的输入并检测到非法输入，它应该怎么做：引发异常（或使用其他错误机制）或什么都不做/忽略错误的输入？
在 Java 中，如果给定空引用作为参数，HashTable 类会抛出 NullPointerException。这有时很烦人，但我认为它可能有优势，因为错误会被及早发现。其他一些方法忽略非法输入，什么也不做。这不那么烦人，通常不会发生任何不好的事情，但可能有一些情况，然后这种行为会导致头痛 - 或者不会？
我不确定，哪种方式更好。所以我问你：你对这个问题怎么看？
【问题讨论】：
肯定抛出异常。异常令人讨厌，故意强迫您对它们做点什么。
这样想，如果你的程序在输入错误时什么都不做，你应该如何让用户知道什么都没发生，为什么？另外，调试一个在错误条件下不执行任何操作的程序需要多长时间？
【讨论】：
我认为它取决于您正在处理的上下文或抽象层。最重要的是要保持一致。如果您在该级别抛出异常，请继续抛出您的异常。如果没有，请检查图层的行为并执行相同的操作。
【讨论】：
这在很大程度上取决于您正在开发的应用程序。
尽管输入非法，但仍坚持下去可能意味着程序的输出不正确，这对于计算药物剂量的应用程序来说是一件非常糟糕的事情。另一方面，如果不会造成任何灾难性后果，那么什么都不做可能是可以的。
另一种选择是将非法输入更改为最接近的合法值（例如，如果整数的范围是 0 - 100，而您收到 -10，则可以将其设置为 0 并继续处理）。
您应该尝试考虑在您编写的特定方法中如何处理错误的可能后果，以及您的错误处理将如何影响整个应用程序。
【讨论】：
假设这是一个公共方法，该方法与调用该方法的人之间的约定是什么？
如果你正在编写这个方法，那么契约就是设计的一部分。你可以选择
最后，这真的取决于方法在做什么以及你对方法的期望。
您可以用 Class 代替 method 并拥有相同的选项。
在某些情况下，您可能无法引发异常 - 即固件嵌入式微控制器。在这些情况下，您必须有一个专门用于处理错误输入并继续处理有效输入的流程。
干杯，
-R
【讨论】：
快速失败：永远不要忽略错误的输入。您可能会隐藏问题并使它们很难找到。
有些人通过Design by Contract (DBC) 将这一点推得很远。
遵循您的项目或公司中已经使用的做法 - 或立即定义它们。
【讨论】：