在哪里捕获和处理空参数

本文关键字：参数 处理 在哪里 | 更新日期: 2023-09-27 18:12:37

当我编码时，我经常问自己同样的问题:

我必须验证所有参数不为空吗?因此，在每个方法中，我将有这样的内容:

if (arg1 == null) 
{
    throw FooException("...");
}
if (arg2 == null) 
{
    throw FooException("...");
}

如果不是，在哪种情况下更可取?

最佳实践是什么

在哪里捕获和处理空参数

还是要看情况。

如果你正在编写一个API供其他团队/组织使用，这种在公共函数上使用前提条件检查的防御性编程可以真正帮助你的用户;当使用外部库时，像"传递给foo()的参数不应该是null"这样有意义的错误消息要比从内部类抛出的NullPointerException要好得多。

但是，在API之外，我认为这样的检查使代码过于混乱。抛出的nullpointerexception通常很容易用调试器跟踪。在支持断言的语言中，您可以考虑使用断言——它们的语法通常不那么麻烦，并且您可以在生产环境中关闭它们，这样检查就不会降低性能。

不幸的是，是的。你应该检查所有的参数。理想情况下，如果你用良好的设计实践编写代码，一个函数最多不应该有超过4到5个参数。

话虽如此，应该总是检查函数条目中的空值，并抛出适当的异常或IllegalArgumentException(我最喜欢的)。

此外，永远不应该将NULL传递给函数，也永远不应该返回NULL。听起来很简单，但它将节省大量的代码和bug。也可以看看NULL设计模式

视情况而定，如果你想要不同的异常，我猜你必须在所有可能得到空值的场合这样做。另一种方法是使用dattype . tryparse()。查一下

希望能有所帮助。

因为无论如何都抛出异常，不验证它们可能只会导致nullpointerexception或类似的情况。我自己也不完全确定什么是最佳实践。

理想情况下，在执行任何可能修改与所述参数相关的任何状态或数据的操作之前，应该始终验证任何参数。最好早点失败，并以一种可管理的方式失败(通过抛出异常)，而不是以不一致的状态/数据结束，然后还必须解决。

你的方法期望某些数据在那里，在某些情况下，假设它实际上在那里应该是安全的(比如在一个私有方法中，它是从其他验证输入的方法调用的)。但是，一般情况下，我建议在下列情况下验证参数:

  • 由用户提供。
  • 作为API的一部分提供。
  • 在系统模块间传递。

这可能值得看一下之前的StackOverflow问题

我觉得这主要取决于常识，还有一点取决于个人喜好。

正如其他人所提到的，如果它是一个公共API，那么您希望尽可能提供清晰的错误消息，因此最好在使用参数之前检查参数，并根据您的示例抛出消息异常。

如果它是内部代码，那么还有两个选择可以考虑:使用断言，或者不需要验证而依赖调试。根据经验，如果代码是我预计其他开发人员将调用的代码，或者如果情况非常微妙，以至于调试起来可能很痛苦，那么我就会放入断言。否则，我就让它失败。

有时可以通过使用Null对象模式来避免这个问题。如果它是一个公共API，我仍然倾向于包括检查。

相关文章：