Question

为什么在返回@NonNull时添加Optional注释？

public Optional<Integer> getInt() {
    return Optional.ofNullable(localInteger);
}

Vs的

@NonNull
public Optional<Integer> getInt() {
    return Optional.ofNullable(localInteger);
}

基于这篇文章：http://www.oracle.com/technetwork/articles/java/java8-optional-2175753.html 我对该文章的Optional的理解是，Optional的重点是尝试阻止在代码中检查null，并且当函数返回null时，它将会而是返回Optional以强制调用者检查它是否为isPresent。

我已经了解到此处描述的Optional<Map>存在问题：https://developer.atlassian.com/blog/2015/08/optional-broken

因此，为Optional添加@NonNull似乎在返回Map类型时为调用者增加了额外的清晰度，但是返回任何Optional类型的所有函数都需要这种清晰度吗？

public Optional<Integer> getInt() {
    return null;
}

和

一样糟糕

@NonNull
public Integer getInt() {
    return null;
}

我认为当返回类型为null时返回Optional是不好的做法吗？（除了上面提到的地图案例或因为null有效的情况，你应该总是添加@NonNull？）

结论到目前为止，我的结论是在返回@NonNull时不添加Optional，如果它可以null然后使用@Nullable进行注释或更好，请不要返回{{1}输入。

Answer 1

感谢您的评论。看来我的理解与评论相符。

当NSAttributedStringKey被“承诺”时返回null似乎通常被视为错误。

我完全同意基于Optional的目的。

然而 ...由于Optional中缺少文档明确表示您不应该返回{我们必须在我们的公司文档中特别注意这一点返回Optional时的{1}}。

Answer 2

@NotNull在运行时断言，发现一个null值。因此，为所有返回Optional的方法添加此批注绝对有意义，因为该方法的调用者希望该方法永远不会返回null而是使用Optional.empty()。

使用@NotNull将有助于防止这些null值遍历应用程序并在不同部分引起奇怪的NPE。这有助于调试问题并更快地找到问题的根源。

返回Optional的IMHO方法应由编译器自动标记为@NotNull，如果有设置/插件可以做到这一点就很好了。

更新：据我了解，in a different question，存在CheckerFramework，它可以更进一步，并且可以在编译时检查空问题 >。与运行时注释相比，将其集成到大型项目中可能会更困难，但是这会使代码基础更加安全。还有一个very good tutorial用于迁移小型示例项目。

使用@NonNull注释返回Optional的函数？

2 个答案: