Null analysis produce invalid warnings

I am not sure wheter it is a bug or may be multi-return methods just can not
be analyzed completely. Changin return "" to value = ""; in the second
method and having single retur in the end did not help either

public static @Nullable String trimNull(@Nullable String value) {
if (value == null) {
return null;
}
if (value.length() > 0) {
value = value.trim();
}
if (value.length() > 0) { //value.length() highlighted
return value;
} else {
return null;
}
}

public static @NotNull String trimBlank(@Nullable String value) {
if (value == null) {
return "";
} else if (value.length() > 0) {
value = value.trim();
}
return value; //value highlighted
}


4 comments
Comment actions Permalink

This is not a bug taking into account @Nullable semantics:
it does mean the reference aliased might be null, not that the value passed to parameter on calling the method might be null. So while you check for null in the first line, calling later value.length() destroys not null assumption.

0
Comment actions Permalink

Eugene Vigdorchik wrote:

This is not a bug taking into account @Nullable semantics: it does
mean the reference aliased might be null, not that the value passed
to parameter on calling the method might be null. So while you check
for null in the first line, calling later value.length() destroys not
null assumption.


Have you guys considered parsing the ESC/java JDK pre/post condition
libraries?

0
Comment actions Permalink

No, this is too heavyweight to be included in the IDE.

0
Comment actions Permalink

Eugene Vigdorchik wrote:

No, this is too heavyweight to be included in the IDE.


I'm curious, it sounds like you'd have to write small parser and store
essentially 1 bit per method per class. In what way is it heavyweight?

0

Please sign in to leave a comment.