Comment déterminer par programme le nom du paramètre lors de la construction d'une ArgumentException?

Question

Lors de la construction d'une exception ArgumentException, un couple de surcharges utilise une chaîne représentant le nom du paramètre de l'argument non valide. Je pense que ce serait bien de ne pas avoir à penser à mettre à jour ce paramètre param à chaque fois que je change le nom du paramètre de la méthode. Existe-t-il un moyen simple de faire cela en utilisant la réflexion?

Mise à jour: grâce aux 2 personnes interrogées jusqu'à présent. Vous répondez bien à la question, mais la solution me laisse toujours avec un mal de tête de maintenance. (OK, un minuscule mal à la tête, mais quand même ...) Pour expliquer, si je devais réorganiser les paramètres plus tard - ou supprimer un paramètre précédent - je ne pas oublier de changer à nouveau mon code de construction d'exception. Est-il possible d'utiliser quelque chose du genre

Object.ReferenceEquals(myParam, <insert code here>)

pour être sûr que je traite avec le paramètre pertinent? De cette façon, le compilateur interviendrait pour éviter que je construise l’exception.

Cela dit, je commence à soupçonner que le "simple" partie de la question initiale pas celle à venir. Peut-être que je devrais me contenter d'utiliser des littéraux de chaîne. :)

Answer 1

La réflexion n'est pas appropriée pour cela.

Vous devrez vous rappeler de bien faire les choses.

Heureusement, FxCop (ou Analyse du code du système d'équipe) vous aidera en signalant toute disparité.

Answer 2

Vous pouvez utiliser un arbre d’expression pour cela. Vous obtiendrez ce que vous voulez au détriment d’une syntaxe étrange. Ex.

public void Resize(int newSize)
{
  if (newSize < 1)
  {
    throw new ArgumentException("Blah", NameOfVariable(() => newSize));
  }
  // ... whatever ...
}

Où NameOfVariable est défini comme:

public static string NameOfVariable(Expression<Func<object>> expressionTree)
{
   var expression = (UnaryExpression)expressionTree.Body;
   var memberExpression = (MemberExpression)expression.Operand;
   return memberExpression.Member.Name;
}

Cela risque également de provoquer un crash au moment de l'exécution si vous transmettez autre chose qu'une expression UnaryExpression à NameOfVariable.

Je ne serais pas surpris si ce code provoque également une plainte de FxCop, ainsi que Joe mentionne que l'utilisation de FxCop est probablement la meilleure façon de procéder.