原始“null”和 Java 8

我知道处理的最佳实践null原语是使用盒装包装器，例如Integer代替int，正如这里所讨论的

原始数据类型为 Null https://stackoverflow.com/questions/11047276/null-for-primitive-data-types

然而，今天的 Java 8 仍然如此吗？ 引入了可选原语，例如OptionalInt, whose OptionalInt.empty()有效地代表了null价值？我的理解是，Optional 只能用于方法返回类型，而不应用作属性本身的类型。 “可为空”基元是否仍应存储为装箱属性？他们应该只是Optional在方法返回类型中？或者存储为OptionalInt在财产本身？

假设你有一个方法

public void logRequest(Integer userID, String content){
    //log content locally or in db or a rest call
}

假设您获得userID来自特定用户的数据库。可能有以下几种可能：

• DB 返回一个用户ID。
• 没有找到id。

所以现在如果没有找到 id，你会传递给什么logRequest?

• 你通过吗null？如果该方法没有适当的空检查怎么办？应该推断出什么null to?
• 如果你通过0 or -1? If null means 0那么它可能与 ID 为的实际用户相矛盾0。怎么区分null和0呢？

当然，上述问题可以通过适当的文档和固定规则来解决，但它会带来更高的维护性并且容易出错。正确编写的代码应该有自己的文档。

现在假设该方法被声明为：

public void logRequest(OptionalInt userID, String content)

该方法本身非常清楚地表明它需要一个可选的参数。因此只有两种情况需要处理：发送适当的参数（这意味着使用0）。如果可选值为空，则方法正确地知道如何处理。 （与之前不同的是，我们必须阅读其文档来预测行为）。

因此，方法声明本身就清楚地表明了行为，而不是文档为您做这件事并依赖文档和随意猜测。选项在这种情况下非常有用。

PS：总感觉有一股掐过的感觉null到一个期望的方法Integer。肯定感觉不对啊！天哪，在 Java 中，潜意识总是将整数视为原语。它们并不意味着被取消。