Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add more Optional methods to ReturnValueIgnored #2282

Closed
wants to merge 3 commits into from

Conversation

pkoenig10
Copy link
Contributor

The return values of almost all Optional instance methods, excluding ifPresent and ifPresentOrElse, should have their return values used.

For cases where you may don't care about the return value, it's better to use isPresent and isEmpty. For example, instead of:

optional.orElseThrow(() -> ...);

Do:

if (optional.isEmpty()) {
    throw ...;
}

As a motivating example, I had some code that was intended to look like:

if (condition) {
    return getOptional().orElseThrow(...);
}

return ...;

But I forgot the return, so the code actually looked like:

if (condition) {
    getOptional().orElseThrow(...);
}

return ...;

Detecting the unused Optional value here would have been useful.

Copy link
Collaborator

@cushon cushon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this!

We'll probably need to put this behind a flag initially to avoid making an atomic breaking change to an existing error. If you don't mind doing that there's an example in 86f8e23, otherwise I can take care of it when I import the PR.

instanceMethod().onExactClass("java.util.Optional").named("isPresent"),
instanceMethod().onExactClass("java.util.Optional").named("isEmpty"));
instanceMethod().onExactClass("java.util.Optional").named("map"),
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FYI we have a separate check just for this one, with a fix that migrates to ifPresent: https://github.com/google/error-prone/blob/master/core/src/main/java/com/google/errorprone/bugpatterns/OptionalMapUnusedValue.java. We were planning to add map here after that cleanup was done.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you want me to remove map from here for now?

instanceMethod().onExactClass("java.util.Optional").named("or"),
instanceMethod().onExactClass("java.util.Optional").named("orElse"),
instanceMethod().onExactClass("java.util.Optional").named("orElseGet"),
instanceMethod().onExactClass("java.util.Optional").named("orElseThrow"));
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Calling orElseThrow to assert an Optional is present and then discarding the return result appears to be more common than the other examples here. I'm not really defending that as a pattern, just saying that making this one an error maybe not be lower priority for us. I'm curious if you've run into examples of that?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Occasionally, but rarely.

Copy link
Contributor Author

@pkoenig10 pkoenig10 Apr 13, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As a reference, SonarLint requires that return values are used for all Optional methods that return non-void values.
https://github.com/SonarSource/sonar-java/blob/d59d157c852ac924f3029ddb8c0aa366501f9fda/java-checks/src/main/java/org/sonar/java/checks/IgnoredReturnValueCheck.java#L68

Maybe we should do the same here?

@pkoenig10
Copy link
Contributor Author

What do you think about matching all non-void instance methods like we do for Stream? This would ensure we match against any methods added in the future.

@cushon
Copy link
Collaborator

cushon commented Apr 20, 2021

What do you think about matching all non-void instance methods like we do for Stream? This would ensure we match against any methods added in the future.

That SGTM, maybe as a follow-up once the flag can be removed?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants