¿Cómo determinar mediante programación el nombre del parámetro al construir una ArgumentException?

Question

Al construir una ArgumentException, un par de sobrecargas toman una cadena que es el nombre del parámetro del argumento no válido.Me imagino que sería bueno no tener que acordarme de actualizar este parámetro ctor cada vez que cambie el nombre del parámetro del método.¿Existe una forma sencilla de hacer esto mediante la reflexión?

Actualizar: gracias a los 2 encuestados hasta ahora.Ambos responden bien a la pregunta, pero la solución todavía me deja con un dolor de cabeza de mantenimiento.(Está bien, un diminuto dolor de cabeza, pero aun así...) Para explicar, si tuviera que reordenar los parámetros más tarde, o eliminar un parámetro anterior, tendría que acordarme de cambiar mi código de construcción de excepción nuevamente.¿Hay alguna manera de que pueda usar algo como

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

¿Para estar seguro de que estoy tratando con el parámetro relevante?De esa manera, el compilador intervendría para evitar que construya mal la excepción.

Dicho esto, estoy empezando a sospechar que la parte "simple" de la pregunta original no es tan directa.Tal vez debería aguantar el uso de cadenas literales.:)

Answer 1

La reflexión no es apropiada para esto.

Tendrás que aguantar recordar para hacerlo bien.

Afortunadamente, FxCop (o Team System Code Analysis) le ayudará señalando cualquier discrepancia.

Answer 2

Podrías usar un árbol de expresión para esto, que obtendrá lo que deseas a costa de una sintaxis extraña.P.ej.

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

Donde NombreDeVariable se define como:

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

Esto también tiene la posibilidad de fallar en tiempo de ejecución si pasa algo que no sea UnaryExpression a NameOfVariable.

No me sorprendería que este código también provocara que FxCop se quejara, y como José menciona que usar FxCop es probablemente la mejor manera de hacerlo.