-
Notifications
You must be signed in to change notification settings - Fork 227
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
S3966: Remove FP on streams special handling #3647
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to drop a few remarks.
The StreamWriter constructor docs says
Unless you set the leaveOpen parameter to true, the StreamReader object calls Dispose() on the provided Stream object when StreamReader.Dispose is called.
In practice it calls Close()
but close eventually calls Dispose()
. In the remarks for the Close() docs
This method calls Dispose, specifying true to release all resources. You do not have to specifically call the Close method. Instead, ensure that every Stream object is properly disposed. You can declare Stream objects within a using block (or Using block in Visual Basic) to ensure that the stream and all of its resources are disposed, or you can explicitly call the Dispose method.
Even in the StreamWriter itself, close() calls Dispose(true).
So the reasoning that Close()
isn't the same thing as Dispose()
is wrong.
I guess it's still ok to remove this example because we were suggesting to replace it with some cumbersome , not nice try-catch replacement.
@@ -1,33 +1,20 @@ | |||
<p>A proper implementation of <code>IDisposable.Dispose</code> should allow for it to be called multiple times on the same object, however this is not | |||
guaranteed and could result in an exception being thrown.</p> | |||
<p>It is best not to rely on this behaviour and therefore make sure an object is disposed only once on all execution paths. This is particularly true | |||
<p>It is best not to rely on this behavior and therefore make sure an object is disposed only once on all execution paths. This is particularly true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is the nested using statements still valid?
This is particularly true when dealing with nested using statements.
I would check with @nicolas-harraudeau-sonarsource on how it's best to word the new implementation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for pinging me @andrei-epure-sonarsource.
I rewrote the rule description with the help of @costin-zaharia-sonarsource.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After discussion with @nicolas-harraudeau-sonarsource we decided to add the rule back to Sonar Way. With the latest changes most of the FPs will disappear and the found issues on peach reveal code which is error prone.
...yzer-dotnet/its/expected/Nancy/Nancy.Tests-{776D244D-BC4D-4BBB-A478-CAF2D04520E1}-S3966.json
Show resolved
Hide resolved
...yzer-dotnet/tests/SonarAnalyzer.UnitTest/TestCases/ObjectsShouldNotBeDisposedMoreThanOnce.cs
Show resolved
Hide resolved
After these changes... will this rule only catch when a resource is manually disposed a second time via |
Additionally, calling dispose twice in this case is not a problem since there is no exception thrown. |
Yes, what's left now is the check that the |
3823e25
to
d76547c
Compare
d76547c
to
cb893fc
Compare
Kudos, SonarCloud Quality Gate passed! 0 Bugs |
...yzer-dotnet/tests/SonarAnalyzer.UnitTest/TestCases/ObjectsShouldNotBeDisposedMoreThanOnce.cs
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Kudos, SonarCloud Quality Gate passed! 0 Bugs |
Fixes #3644