-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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 @CheckReturnValue to package-info.java (and @CanIgnoreReturnValue as appropriate) #863
Comments
Sure! I tried to keep those annotations in sync with Guava's usages, but I might have missed a couple cases and for these divergences. I guess that I missed your switch over and will emulate 67350a3 and bd5a7777. You are welcome to send a PR or commit the changes, else I will try to take care of it this evening. I meant to cut a release last week so we can get this out pretty quick for you. |
Awesome, thanks for handling this! A bit more background: internally, we've made "CRV the default", so previously-safe API changes like Thanks again --- hope all is well. |
How lenient would you like me to be regarding I would guess that you want it to be strict but, due to the enormous code base, deferred some refactorings until later. Do you want Caffeine's apis to be lenient or strict? I think that I'd need some more assistance to make sure that I did not fubar this and cause headaches. |
This annotation is used by ErrorProne and Spotbugs to warn users when they ignore the results of a method call. This is now the default behavior rather than a few opt in cases. In rare cases the result is an ignorable signal, like List's add(e) or our LoadingCache.refresh(k), so @CanIgnoreReturnValue is used to disable the check for those methods. For all other methods then users can suppress the warning when desired.
Released in 3.1.3 |
Hey Ben,
In our quest to stomp out accidentally ignored return value bugs, I was hoping you'd be able to add ErrorProne's
@CheckReturnValue
to apackage-info.java
(in each package that caffeine owns), as well as@CanIgnoreReturnValue
to methods that are "ignorable".Specifically, we noticed that
refresh()
went from beingvoid
to returning aFuture
--- and that change is going to cause problems with errorprone'sFutureReturnValueIgnored
check.Does this sound reasonable?
The text was updated successfully, but these errors were encountered: