方法是否应该忽略非法输入或引发异常？
如果一个方法检查它的输入并检测到非法输入，它应该做什么：引发异常（或使用另一个错误机制）或不执行任何操作/忽略错误的输入？
在 Java 中，如果给定空引用作为参数，HashTable 类将抛出 NullPointerException。 这有时很烦人，但我认为它可能有优点，因为错误会被及早发现。 其他一些方法会忽略非法输入，不执行任何操作。 这不那么烦人，通常不会发生什么坏事，但可能有一些情况，那么这种行为会导致头痛 - 或不会？
我不确定哪种方式更好。 那我问你：你对这个问题怎么看？
If a method checks it's input and detects illegal input, what should it do: Raise an exception (or use another error-mechanism) or do nothing/ignoring on the wrong input?
In Java the HashTable-class throws an NullPointerException if given null-references as parameter. This is sometimes annoying, but I think it may have advantages, because errors are catched early. Some other methods ignore illegal input, doing nothing. That is less annoying and normally nothing bad is happen, but there might be cases, then this behaviour causes headaches - or not?
I'm not sure, which way is better. So I ask you: What do you think on this question?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
肯定会抛出异常。 异常是故意令人烦恼的，迫使你对它们做一些事情。
这样想，如果您的程序对错误输入不执行任何操作，那么您应该如何让用户知道什么都没有发生以及为什么？ 另外，调试一个在错误情况下不执行任何操作的程序需要多长时间？
Definitely throw an exception. Exceptions are annoying on purpose to force you to do something about them.
Think of it this way, if your program does nothing on bad input, how are you supposed to let the user know that nothing happened and why? Also, how long will it take you to debug a program that does nothing on error conditions?
我认为这取决于您正在处理的上下文或抽象层。 最重要的是要保持一致。 如果您在该级别抛出异常，请继续抛出您的异常。 如果没有，请检查图层的行为方式并执行相同的操作。
I think that it depends on the context or layer of abstraction you are working on. The most important thing is to be consistent. If you are throwing exceptions in that level, go ahead and throw your exception too. If not, check how the layer is behaving and do the same.
这在很大程度上取决于您正在开发的应用程序。
尽管输入非法，但继续执行可能意味着程序的输出不正确，这对于计算药物剂量的应用程序来说将是一件非常糟糕的事情。 另一方面，如果不会造成灾难性的结果，那么什么也不做可能就没有问题。
另一种选择是将非法输入更改为最接近的合法值（例如，如果整数的范围是 0 - 100，并且您收到 -10，则可以将其设置为 0 并继续处理）。
您应该尝试考虑如何处理正在编写的特定方法中的错误的可能后果以及错误处理将如何影响整个应用程序。
This depends very much on the application that you're developing.
Soldiering on despite illegal inputs may mean that the output of the program is incorrect, which for an application that calculates medicine doses would be a very Bad Thing. On the other hand, if nothing catastrophic will result then doing nothing will probably be OK.
Another option is to change the illegal inputs to the closest legal value (e.g. if the range for an integer is 0 - 100, and you receive -10, it might be fine to set it to 0 and continue processing).
You should try to think about the possible consequences of how you handle errors in the particular method you're writing and how your error-handling will affect the overall application.
假设这是一个公共方法，该方法和调用该方法的人之间的契约是什么？
如果您正在编写此方法，那么契约就是设计的一部分。 您可以选择以
最后，这实际上取决于该方法正在做什么以及您对该方法有什么期望。
您可以用类替换方法并具有相同的选项。
在某些情况下，您可能无法引发异常 - 即固件嵌入式微控制器。 在这些情况下，您必须设计一个流程来处理错误输入并继续处理有效输入。
干杯，
-R
Assuming this is a public method, what is the contract between the method and those calling this method?
If you are writing this method, then the contract is part of the design. You can elect to
In the end, it really depends on what the method is doing and what expectations you have of the method.
You could substitute Class for method and have the same options.
In some cases, you may not be able to raise an exception - i.e. firmware-embedded microcontrollers. In those cases you must have a process designed for handling erroneous input and continuing to process valid input.
Cheers,
-R
快速失败：永远不要忽略错误的输入。 您可能会隐藏问题并使它们很难找到。
有些人通过契约设计（DBC）将这一点推得更远。
遵循您的项目或公司中已使用的实践 - 或立即定义它们。
Fail Fast: Never ignore wrong input. You may hide problem and make them very hard to find.
Some push this very far with Design by Contract (DBC).
Follow the practices that are already used in your project or in your company - or define them now.