Pass correct parameterName to ArgumentException

[terrajobst]

Find places where nameof(...) is passed as the first (rather than second) argument to ArgumentException. Also places where nameof is used as the argument name in an ArgumentException (or derived type) but where it's not referring to a parameter.

Category: Reliability Usage

Examples to detect:

Single-argument nameof (or a literal string that matches the name of a parameter). Fixer: change to call the two argument constructor, pass null for the first parameter.

public void SomeMethod(string formatted)
{
 if (!Helper.TryParse(arg, out Parsed parsed))
 {
 throw new ArgumentException(nameof(formatted));
 }
}

Two argument call, first one looks like the parameter. Flip the argument order.

public void SomeMethod(string formatted)
{
 if (!Helper.TryParse(arg, out Parsed parsed))
 {
 throw new ArgumentException(
 nameof(formatted),
 string.Format(Resources.DidNotParse, formatted));
 }
}

Two argument call, paramName is a literal, but not a parameter name. (No fixer, just squiggle the argument.)

public void SomeMethod(string formatted)
{
 if (!Helper.TryParse(arg, out Parsed parsed))
 {
 throw new ArgumentException(
 string.Format(Resources.DidNotParse, formatted),
 "input");
 }
}

Two argument call, paramName is a literal, but not nameof. (Fixer: use nameof)

public void SomeMethod(string formatted)
{
 if (!Helper.TryParse(arg, out Parsed parsed))
 {
 throw new ArgumentException(
 string.Format(Resources.DidNotParse, formatted),
 "formatted");
 }
}

Examples to not detect:

Probably wrong (based on the parameter names), but probably shouldn't warn; since we're kinda guessing.

public static void ThrowArgumentException(string param, string msg)
{
 throw new ArgumentException(param, msg);
}

When the parameter name comes from a variable rather than a literal, don't squiggle.

public static void ThrowArgumentException(string msg, string param)
{
 throw new ArgumentException(msg, param);
}

public void SomeMethod(string formatted, int idx)
{
 string argFail = null;
 string msg = null;

 if (!Helper.TryParse(arg, out Parsed parsed))
 {
 argFail = "formatted";
 msg = string.Format(Resources.DidNotParse, formatted);
 }
 else if (parsed.Length < idx)
 {
 // Disregard that ArgumentOutOfRangeException is better here.
 argFail = "idx";
 msg = string.Format(Resources.OutOfRange, idx, parsed.Length);
 }

 if (argFail != null)
 {
 throw new ArgumentException(msg, argFail);
 }
}

[jeffhandley]

Estimates:

• Analyzer: Medium
• Fixer: Not Applicable

[jeffhandley]

A fixer is tough here because we don't know what message to insert into the parameter list. Perhaps we could pass in nameof(...) also as the message.

[Edit by @bartonjs: Digging in a little deeper, it looks like new ArgumentException(nameof(something)) => new ArgumentException(null, nameof(something)) is probably the right answer]

[jeffhandley]

Based on this guidance, we can update the estimates:

• Analyzer: Medium
• Fixer: Small

[buyaa-n]

Just found we have analyzer for ArgumentException and its descendants, some rules might not covered and no fixer implemented I assume i would update this analyzer (if needed) and add fixer implementation. @mavasani please let me know what you think

[buyaa-n]

There is case not covered above:

 public async Task ArgumentException_NoArguments_Warns()
 {
 await VerifyCS.VerifyAnalyzerAsync(@"
 public class Class
 {
 public void Test(string first)
 {
 throw new System.ArgumentException();
 }
 }",
 GetCSharpNoArgumentsExpectedResult(6, 31, "ArgumentException"));
}

The question is do we want fixer for this (possibly new ArgumentException() => new ArgumentException(null, nameof(first)))