什么时候在Java中注释为@NotNull合适？
这是我在这里的第一个问题，我对Java很陌生，如果这是一个愚蠢的问题，请原谅。
我正在使用JavaDocs和注释从内部“记录”我的应用程序的预期行为，但我只是好奇在一个永远不会返回null的方法上使用@NotNull是否合适或良好，但可能是由于未来的开发人员错误。
谢谢。
共有3个答案
是的，使用@NotNull是一种很好的做法。@NotNull注释实际上是一个明确的约定，声明了以下内容：
- 方法不应返回null。
- 变量（如字段、局部变量和参数）不能保存空值。
所以为了保持简单，这是一个很好的练习。
据我所知，在全球范围内没有强制标准来使用这些类型的注释。在编写公共API时使用它们是有道理的，但这是特定于项目的。
在任何情况下，如果有助于代码的清晰性和易读性，请随时在项目中这样做。
使用带有注释的javadocs并不是一种反模式。
此外，如果您正在考虑警告您的方法的用户它不应该返回null，但有可能发生这种情况（因为您无法强制执行它），您可能需要查看可选类。
这实际上取决于您使用的工具。NotNull注释实际上没有做任何事情。实际上，不同的库提供了几种不同的NotNull注释。除了发出程序员意图的信号外，他们没有一个人做任何事情。
要使注释发挥作用，需要将其与处理注释的工具（在编译时或运行时）相结合，并对代码或html" target="_blank">数据应用一些验证。例如：
- IntelliJ IDEA包含一些工具，可以检查代码是否符合您包含的可空性注释
- Bean验证可以在运行时用于检查，例如，用户输入是否违反可空性约束
即使没有工具，我也会说，是的，这些注释可以用于表示意图。如果注释变得不真实，则始终可以删除该注释。
在您的情况下，对于代码库的所有贡献者来说，使用一个工具（如IntelliJ idea）将是一个好主意，该工具将在编译时检查是否符合这些注释。这将帮助您避免您描述的开发人员错误类型。
-
问题内容： 使用Java 注释的最佳实践是什么？为什么？ 用注解标记每个覆盖的方法似乎是过大的。是否存在某些编程情况要求使用和其他不应该使用的情况？ 问题答案： 每次你重写一种方法都有两个好处时使用它。这样做是为了使你能够利用编译器检查的优势，以确保你认为自己确实覆盖了某个方法。这样，如果你犯了拼写错误的方法名称或不正确匹配参数的常见错误，将会警告你方法实际上并没有像你认为的那样覆盖。其次，它使你
-
问题内容： 我不明白为什么Java注释中没有继承关系，就像Java类一样。我认为这将非常有用。 例如：我想知道给定的注释是否为验证者。通过继承，我可以自反地浏览超类，以了解此注释是否扩展了。否则，我该如何实现？ 那么，谁能给我这个设计决定的理由？ 问题答案： 关于未采用这种方式进行设计的原因，你可以在JSR 175设计常见问题解答中找到答案，其中说： 你为什么不支持注释子类型化（一种注释类型扩展了
-
（1）重载是多态的集中体现，在类中，要以统一的方式处理不同类型数据的时候，可以用重载。 （2）重写的使用是建立在继承关系上的，子类在继承父类的基础上，增加新的功能，可以用重写。 （3）简单总结： 重载是多样性，重写是增强剂； 目的是提高程序的多样性和健壮性，以适配不同场景使用时，使用重载进行扩展； 目的是在不修改原方法及源代码的基础上对方法进行扩展或增强时，使用重写； 生活例子： 你想吃一碗面，我
-
我有一个简单的方法来获取给定公司ID的文档列表。方法如下： 我想使用Javax验证约束来确保传入的companyId不是null。但它似乎没有任何影响，因为我能够传递一个null值，它向下流到存储库上的findByCompany调用。我还在NotNull之前添加了Valid来强制验证，但这也没什么用。 我总是可以写几行代码来检查null值，但我想使用javax。验证注释，使代码更具可读性和简洁性。
-
问题内容： 我怕可变参数。我不知道该怎么用。 另外，让人们随心所欲地传递争论是很危险的。 什么样的上下文示例将是使用它们的好地方？ 问题答案： 对于需要处理不确定数目的对象的任何方法，Varargs都是有用的。一个很好的例子是。格式字符串可以接受任意数量的参数，因此你需要一种机制来传递任意数量的对象。
-
问题内容： 我刚刚开始在Java 8中使用注释，并得到了一些意外的结果。 我有这样的方法： 我编写了一个JUnit测试，为参数searchList传递了空值。我原以为会发生某种类型的错误，但好像没有注释就通过了。这是预期的行为吗？据我了解，这是允许您跳过编写样板空检查代码。 对于@NotNull应该做什么的解释将不胜感激。 问题答案： 和自己做什么。它们应该充当文档工具。 该注释提醒您在以下情况下