After installing FindNPE, errors like the example on the Inroduction page are shown. However such NPE hazards are generally quite few. NPEs more likely happen by having methods which are assumed to return a non-null value but in fact can return null. Without preparation, also FindNPE cannot detect such inter-method NPE hazards:
To make visible the obviously not reported problem, the first step is to annotate the class with @NonNullByDefault (which is equivalent to annotating each method /parameter / field of the class with @NonNull):
@NonNull for a method means, that all return statements are checked to return a non-null value, so we have a violation of this contract in methodA. Similar, it would mean for parameters and fields, that they can only be assigned a non-null value. Now, to solve the reported problem, one can annotate the method explicitely with @CanBeNull by just applying the proposed quick fix:
Finally, the desired error is displayed, saying that "s" can be null when it is accessed. The programmer can fix this error like here:
The reason why such errors can not be fixed automatically, is mainly because the error could also have been fixed differently by coding that methodA not returns null but e.g. an empty string. So it has to be decided whether the calling method or the called method has to be fixed. This choice depends on what the programmer "had in mind" whether the method is allowed to return null or not allowed to do so. Of course it can also be that he never thought about it and is forced to do so right now. The NPE annotations can be used to explicitely express the desired contract.