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

Sonar: Make Attempt transient in RetryException #67

Merged
merged 1 commit into from
Mar 30, 2021

Conversation

sleberknight
Copy link
Member

Mark the Attempt field in RetryException as transient to make Sonar
happy.

While technically Sonar rule java:S1948 (Fields in a "Serializable"
class should either be transient or serializable) is true, it seems
highly unlikely that an exception would be serialized to disk during
any processing. The rule gives the example of a JEE application server
flushing objects to disk under heavy load, but again it seems very
unlikely that an exception would ever be serialized, since exceptions
generally need to be handled (or simply propagated) "right now".

If I am wrong about this behavior and a RetryException ever gets
serialized to disk, and then gets de-serialized somewhere else, and then
someone attempts (ha, a pun) to call getNumberOfFailedAttempts(), they
could get a NPE. While not lovely, I'm not going to (at present unless
someone shows me a real-life example of this happening) modify the
getNumberOfFailedAttempts() method to handle this case other than to
check that the lastFailedAttempt is non-null, and throw an
IllegalStateException if it actually is null. So they will receive
an IllegalStateException with an explanation instead of an NPE, which
ultimately I suppose is better.

Mark the Attempt field in RetryException as transient to make Sonar
happy.

While technically Sonar rule java:S1948 (Fields in a "Serializable"
class should either be transient or serializable) is true, it seems
highly unlikely that an exception would be serialized to disk during
any processing. The rule gives the example of a JEE application server
flushing objects to disk under heavy load, but again it seems very
unlikely that an exception would ever be serialized, since exceptions
generally need to be handled (or simply propagated) "right now".

If I am wrong about this behavior and a RetryException ever gets
serialized to disk, and then gets de-serialized somewhere else, and then
someone attempts (ha, a pun) to call getNumberOfFailedAttempts(), they
could get a NPE. While not lovely, I'm not going to (at present unless
someone shows me a real-life example of this happening) modify the
getNumberOfFailedAttempts() method to handle this case other than to
check that the lastFailedAttempt is non-null, and throw an
IllegalStateException if it actually is null. So they will receive
an IllegalStateException with an explanation instead of an NPE, which
ultimately I suppose is better.
@sleberknight sleberknight added the code cleanup Fix issues reported by Sonar or any other code analysis tools label Mar 30, 2021
@sleberknight sleberknight added this to the 0.5.0 milestone Mar 30, 2021
@sleberknight sleberknight requested a review from chrisrohr March 30, 2021 00:49
@sonarqubecloud
Copy link

Kudos, SonarCloud Quality Gate passed!

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

100.0% 100.0% Coverage
0.0% 0.0% Duplication

@chrisrohr chrisrohr merged commit dfaef0b into master Mar 30, 2021
@chrisrohr chrisrohr deleted the sonar-make-Attempt-transient-in-RetryException branch March 30, 2021 11:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
code cleanup Fix issues reported by Sonar or any other code analysis tools
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants