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

Turn on argument exception analyzer on runtime, fix warnings found #38578

Merged
merged 5 commits into from
Jul 2, 2020

Conversation

buyaa-n
Copy link
Member

@buyaa-n buyaa-n commented Jun 29, 2020

Related to #33763
Most warnings fixed with #35717 but the analyzer wasn't turned with the PR as it needs updated analyzer. Now the runtime repo is using updated analyzers so we can turn it on

@buyaa-n buyaa-n added the code-analyzer Marks an issue that suggests a Roslyn analyzer label Jun 29, 2020
@buyaa-n buyaa-n added this to the 5.0.0 milestone Jun 29, 2020
Copy link
Member

@stephentoub stephentoub left a comment

Choose a reason for hiding this comment

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

Nice. Thanks.

if (namedProperties.Length != propertyValues.Length)
throw new ArgumentException(SR.Arg_ArrayLengthsDiffer, "namedProperties, propertyValues");
if (namedFields.Length != fieldValues.Length)
throw new ArgumentException(SR.Arg_ArrayLengthsDiffer, "namedFields, fieldValues");
#pragma warning restore CA2208
Copy link
Member

Choose a reason for hiding this comment

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

Just to confirm, we're happy with these argument exception names?

Copy link
Member Author

Choose a reason for hiding this comment

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

combination of arguments found 2-3 times in previous PR, and we have suppressed it. I would say we are OK with it instead of happy 😄. We could change the analyzer to not warn in this case but not sure the amount of work for calculating that worth for this rare case scenario

@@ -240,7 +240,7 @@ public Icon(string fileName)
public Icon(Type type, string resource)
{
if (resource == null)
throw new ArgumentException(nameof(resource));
throw new ArgumentNullException(nameof(resource));
Copy link
Member Author

Choose a reason for hiding this comment

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

AssertExtensions.Throws<ArgumentException>(null, () => new Icon(typeof(Icon), null)); test is failing as the Windows implementation of this method is not checking this condition and not throwing, instead directly calling type.GetTypeInfo().Assembly.GetManifestResourceStream(type, resource) which is called for Unix implementation after these checks in row 249.

This kind of pattern happening for most of the Unix implementation updates in this PR and causing test failures. I think parameterName update for ArgumentExceptions is fine, i can fix tests by checking the OS, but is it OK to throw different exceptions (ArgumentNullException instead ArgumentException) for the same method but different OS?
CC @bartonjs @stephentoub

Copy link
Member

Choose a reason for hiding this comment

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

Absent other data, it sounds like we should change the Windows implementation to throw the appropriate ArgumentNullException.

@bartonjs
Copy link
Member

bartonjs commented Jul 1, 2020

@safern Any objection to the exception normalization across OSes here? It seems like an improvement to me.

@buyaa-n buyaa-n requested a review from safern July 1, 2020 22:45
Copy link
Member

@safern safern left a comment

Choose a reason for hiding this comment

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

Thanks, these normalization of the drawing exceptions across OSs was something I had raised before and that wanted to tackle, I agree it is an improvement.

@buyaa-n buyaa-n merged commit 06fa941 into dotnet:master Jul 2, 2020
@ghost ghost locked as resolved and limited conversation to collaborators Dec 8, 2020
@buyaa-n buyaa-n deleted the turn_on_arg_ex branch December 10, 2020 07:19
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-Meta code-analyzer Marks an issue that suggests a Roslyn analyzer
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants