即使我知道该方法无法返回错误的输入，我也应该验证方法调用的返回值吗？

我想知道我是否应该通过验证方法调用的返回值是否符合我的期望来进行防御，即使我知道我正在调用的方法将满足此类期望也是如此。

给予

User getUser(Int id)
{
    User temp = new User(id);
    temp.setName("John");

    return temp;
}

我应该做吗

void myMethod()
{
    User user = getUser(1234);
    System.out.println(user.getName());
}

要么

void myMethod()
{
    User user = getUser(1234);

    // Validating
    Preconditions.checkNotNull(user, "User can not be null.");
    Preconditions.checkNotNull(user.getName(), "User's name can not be null.");

    System.out.println(user.getName());
}

我是在概念上问这个问题。如果我知道我正在调用的方法的内部工作原理。是因为我写了它，还是因为检查了它。它返回的可能值的逻辑符合我的先决条件。跳过验证是“更好”还是“更合适”，还是在继续执行我当前正在实现的方法之前，即使它总是可以通过，我仍然应该避免错误的值。

我从所有答案中得出的结论（请随意得出结论）：

• 该方法在过去表现出不当行为
• 该方法来自不受信任的来源
• 该方法在其他地方使用，没有明确声明其后置条件

• 该方法与您的方法紧密相关（有关详细信息，请参见选择的答案）
• 该方法使用适当的文档，类型安全性，单元测试或后置条件检查等明确定义其合同。
• 性能至关重要（在这种情况下，调试模式声明可以用作混合方法）

这取决于getUser和myMethod更改的可能性，更重要的是，它们彼此独立更改的可能性。

如果您以某种方式肯定地知道getUser在将来永远不会改变，那么是的，这是浪费时间进行验证，就像i在i = 3;声明之后立即浪费时间进行验证一样（值3）。实际上，您并不知道。但是您知道一些事情：

• 这两个功能是否“一起生活”？换句话说，他们是否拥有相同的人员来维护它们，它们是否属于同一文件，因此他们是否有可能彼此保持“同步”？在这种情况下，添加验证检查可能是多余的，因为这仅意味着每次两个函数更改或重构为不同数量的函数时，都必须更改（并可能产生错误）更多代码。

• getUser函数是否是具有特定合同的书面API的一部分，而myMethod仅仅是另一个代码库中的该API的客户端？如果是这样，您可以阅读该文档以了解您是否应该验证返回值（或预先验证输入参数！），或者盲目遵循快乐路径是否真的安全。如果文档中没有明确说明，请维护人员进行修复。

• 最后，如果该特定函数过去以突然破坏代码的方式突然改变了其行为，那么您将无异于对其偏执。错误倾向于聚集。

请注意，即使您是两个函数的原始作者，上述所有内容均适用。我们不知道这两个功能是否会在它们的余生中“一起生活”，或者它们是否会慢慢分散到单独的模块中，或者您是否以某种方式将自己与老一辈的臭虫打成一片getUser的版本。但是您可能可以做出相当不错的猜测。

Ixrec的回答很好，但是我将采用不同的方法，因为我认为值得考虑。出于讨论的目的，我将讨论断言，因为这是您Preconditions.checkNotNull()传统上被称为您的名字。

我想建议的是，程序员常常高估了他们确定某种事物将以某种方式表现的程度，而低估了这种行为的后果。另外，程序员通常没有意识到断言的强大功能。随后，以我的经验，程序员断言的频率比他们应有的少。

我的座右铭是：

您应该一直问自己的问题不是“我应该坚持吗？” 但是“我有什么要断言的吗？”

自然，如果您完全确定某件事是以某种方式表现的，那么您将避免断言它确实以这种方式表现，并且在大多数情况下是合理的。如果您不信任任何东西，那么实际上不可能编写软件。

但是，即使是这个规则也有例外。奇怪的是，以Ixrec为例，存在一种情况，非常需要遵循确实在一定范围内int i = 3;的断言i。在这种情况下，i尝试各种假设情景的人很可能会更改此情况，并且随后的代码依赖于i某个值在一定范围内，并且通过快速查看以下代码，并不能立即看出其含义。可接受的范围是。因此，int i = 3; assert i >= 0 && i < 5;乍一看似乎很荒谬，但是如果您考虑一下，它会告诉您可以使用i，并且还告诉您必须停留的范围。断言是最好的文档类型，因为它是由机器强制执行的，因此是一个完美的保证，并且它与代码一起被重构，因此始终保持相关性。

您的getUser(int id)示例与该assign-constant-and-assert-in-range示例之间的关系不是很远。根据定义，您会看到，当事物表现出与我们预期的行为不同的行为时，就会发生错误。没错，我们不能断言所有事情，因此有时会进行一些调试。但是，业内公认的事实是，我们越早发现错误，花费越少。您应该问的问题不仅是如何确保getUser()永远不会返回null（也永远不会返回名称为null的用户），而且，如果其余的代码都将在其中发生什么坏事呢？事实上，有一天会返回意外的结果，并且通过快速查看其余代码以准确了解期望的结果是多么容易getUser()。

如果意外行为会导致数据库损坏，那么即使您有101％的把握不会发生，您也应该断言。如果null用户名会引起一些奇怪的神秘的，不可追踪的错误，那么可能会导致数千行下降，并在数十亿个时钟周期之后发生，那么最好是尽早地使失败。

因此，即使我不同意Ixrec的回答，我还是建议您认真考虑以下事实：断言不花任何钱，因此，通过自由地使用断言，实际上并没有什么可以失去的，只有收获。

绝对没有

调用方永远不要检查它所调用的函数是否遵守其合同。原因很简单：潜在的调用者很多，从概念上讲，对于每个调用者来说，复制检查其他函数结果的逻辑都是不切实际的甚至是错误的。

如果要进行任何检查，则每个功能应检查自己的后置条件。后置条件使您有信心正确实现了该功能，并且用户将能够依赖于您的功能合同。

如果某个功能不打算返回null，则应将其记录在案并成为该功能合同的一部分。这就是这些合同的重点：为用户提供了一些可以依赖的不变式，因此在编写自己的函数时，他们面临的障碍更少。

如果null是getUser方法的有效返回值，则您的代码应使用If（不是）异常来处理它-这不是特例。

如果null不是getUser方法的有效返回值，则getUser中存在错误-getUser方法应引发异常或以其他方式修复。

如果getUser方法是外部库的一部分，或者无法更改，并且您希望在返回null的情况下引发异常，则包装类和方法以执行检查并引发异常，以便对getUser的调用在您的代码中是一致的。

我认为您的问题的前提是不正确的：为什么要使用空引用开头？

该空对象模式是返回的对象，基本上什么都不做的方式：“没有用户”，而不是返回NULL您的用户，返回表示对象

该用户将处于非活动状态，名称为空，并且其他非空值表示“此处无内容”。主要好处是您不需要乱扔程序，就可以使检查，日志记录等无效，您只需使用对象即可。

为什么算法要关心空值？步骤应相同。拥有一个返回零的空对象，空白字符串等，这同样容易并且更加清晰。

这是一个检查空值的代码示例：

User u = getUser();
String displayName = "";
if (u != null) {
  displayName = u.getName();
}
return displayName;

这是使用空对象的代码示例：

return getUser().getName();

哪个更清楚？我相信第二个是。

虽然该问题被标记为java，但值得注意的是，在使用引用时，空对象模式在C ++中确实非常有用。Java引用更像C ++指针，并且允许null。C ++引用无法保存nullptr。如果有人想拥有类似于C ++中的null引用的内容，那么null对象模式是我所知道的唯一实现此目的的方法。

通常，我会说这主要取决于以下三个方面：

1. 健壮性：调用方法可以处理该null值吗？如果一个null值可能会导致RuntimeException我建议检查-除非复杂度低并且被调用/调用方法是由同一作者创建的，并且null不是预期的（例如，两者都private在同一包中）。

2. 代码责任：如果开发人员A负责该getUser()方法，而开发人员B使用它（例如，作为库的一部分），则强烈建议您验证其值。仅仅因为开发者B可能不知道导致潜在null返回值的更改。

3. 复杂度：程序或环境的总体复杂度越高，我建议验证返回值的建议就越多。即使您确定null在调用方法的上下文中它今天不可能存在，也可能是您必须getUser()为另一个用例进行更改。一旦消失了几个月或几年，并且添加了几千行代码，这可能是一个陷阱。

另外，我建议null在JavaDoc注释中记录潜在的返回值。由于大多数IDE中都突出显示了JavaDoc描述，因此无论对谁使用，这都是一个有用的警告getUser()。

/** Returns ....
  * @param: id id of the user
  * @return: a User instance related to the id;
  *          null, if no user with identifier id exists
 **/
User getUser(Int id)
{
    ...
}

您绝对不必。

例如，如果您已经知道返回永远不能为空-为什么要添加空检查？添加空检查不会破坏任何东西，但这只是多余的。最好不要编写冗余逻辑，只要您可以避免它。