1

In my Spring project there is a service

  public Pageable<MyObject>findAccount(String accountExternalId){
  if (accountExternalId== null) {
            throw new ProjectException("Missing account");
     }
  ...
}

So when I java 5 arguments I have to make 5 ifs in which to check for null input objects. Not to do this I want to use javax.annotation.Nonnull and javax.annotation.CheckForNull and to do something like.

public Pageable<MyObject>findAccount(@Nonnull String accountExternalId){
         ...
  }

and use findbugs

  <groupId>
        com.google.code.findbugs
  </groupId>
  <artifactId>
        findbugs
  </artifactId>

So I am wondering how this annotation prevent users not to pass Null values? Or it only annotate that you have not to pass null and is only with informational purpose?

Xelian
  • 16,680
  • 25
  • 99
  • 152
  • possible duplicate of [Avoiding "!= null" statements in Java?](http://stackoverflow.com/questions/271526/avoiding-null-statements-in-java) – Mordechai Jun 28 '15 at 12:29

2 Answers2

2

So I am wondering how this annotation prevent users not to pass Null values? Or it only annotate that you have not to pass null and is only with informational purpose?

The second one.

However FindBugs also uses some of those annotation for its analysis; for instance, if you have a @Nullable parameter (or method return value) and FindBugs detects in the code that you don't check that the parameter (or method return value) is null before using it, it will raise an issue.

If @Nonnull then it basically says that it's the caller's responsibility to ensure that non null parameters are passed to the method or the method does not return null.

(not sure about the difference between @CheckForNull and @Nullable though)

fge
  • 119,121
  • 33
  • 254
  • 329
  • Ok so even if I write @Nonnull I still have to make the if checks and to throw exceptions if null is passed? – Xelian Jun 28 '15 at 14:34
  • @fge here the difference is explained: https://stackoverflow.com/questions/12301570/javax-annotation-nullable-vs-checkfornull – JonyD Aug 10 '17 at 10:36
0

You have two options:

  • permit client code to pass null values, but throw a run-time error if it does so.
  • prevent client code from passing null values, by never running code that might do so.

The run-time checking approach is used by your sample code. You can also generate run-time checks from @Nonnull annotations.

The compile-time checking approach (also known as "static analysis") is preferable, and is the FindBugs approach. The library author writes the library's contract using the @Nonnull annotation; the static analysis is run when building any library code; and if the static analysis indicates that the client code may violate the library's contract, then the client code should not be run.

If the static analysis is always run when building client code, then there is no need for run-time checks in the library. Even if you choose to include run-time checks in the library, the static analysis is still useful because it finds bugs at compile time, before testing or deployment.

If you want a guarantee, you may not want to use FindBugs. FindBugs is a best-effort tool that finds some errors, but it makes no attempt to find all errors. Furthermore, FindBugs treats @NonNull as meaning the same thing as @Nullable when applied to a formal parameter (!).

You might want to consider alternative tools for static checking. One example is the Checker Framework. Unlike FindBugs, it gives a correctness guarantee, and it uses is much more precise analysis. The downside is that you have to annotate your code with @Nullable annotations, but you already seem willing to do so.

mernst
  • 7,437
  • 30
  • 45