You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
From the history of CheckOptionalEmptiness I'm not entirely certain which exact issues it is intended to protect against but I ran into a surprise with j.u.Optional::or that led me to map out a number of false positive warnings. These seem to revolve around
the initial value passed to an Optional factory is ignored
fallback providers are not recognized
Both cases fail with [NullAway] Invoking get() on possibly empty Optional o
Some of these look like #557 but I don't see other related issues.
All of my cases for posterity:
Objectvalue;
Optional<Object> o;
o = Optional.empty();
if (o.isPresent()) {
value = o.get(); // true negative
} else {
value = o.get(); // true positive
}
if (o.isEmpty()) {
value = o.get(); // true positive
} else {
value = o.get(); // true negative
}
o = Optional.of(newObject());
value = o.get(); // false positiveo = Optional.ofNullable(newObject()); // huh, no ErrorProne lint!value = o.get(); // false positivetry {
o = Optional.of(newObject());
} catch (Exceptione) {
thrownewRuntimeException();
}
value = o.get(); // false positivetry {
o = Optional.of(newObject());
if (o.isEmpty()) {
thrownewRuntimeException();
}
value = o.get(); // true negative
} catch (Exceptione) { }
o = o.isPresent() ? o : Optional.of(newObject());
value = o.get(); // false positiveo = o.isEmpty() ? Optional.of(newObject()) : o;
value = o.get(); // false positiveo = o.or(() -> Optional.of(newObject()));
value = o.get(); // false positivevalue = o.orElse(newObject()); // true negativevalue = o.orElseGet(() -> newObject()); // true negativevalue = o.orElseGet(Object::new); // true negativevalue = o.orElseThrow(); // true negativevalue = o.orElseThrow(RuntimeException::new); // true negative
@commonquail thanks for the detailed report! My guess is for many of these cases we need to model more Optional APIs. (The or() case looks trickier.) We would welcome a PR for better support here.
From the history of CheckOptionalEmptiness I'm not entirely certain which exact issues it is intended to protect against but I ran into a surprise with
j.u.Optional::or
that led me to map out a number of false positive warnings. These seem to revolve aroundOptional
factory is ignoredBoth cases fail with
[NullAway] Invoking get() on possibly empty Optional o
Some of these look like #557 but I don't see other related issues.
All of my cases for posterity:
using JDK 17 and
The text was updated successfully, but these errors were encountered: