2009-07-10 7 views
17

no sé cuántas veces incontables que he tenido que escribir código para validar los argumentos de cadena:C#: validación de argumentos:/cadenas vacías nulos

public RoomName(string name) 
{ 
    if (string.IsNullOrEmpty(name)) 
    { 
     throw new ArgumentException("Cannot be empty", "name"); 
    } 
} 

¿Hay alguna forma de evitar esto? ¿Hay algún mecanismo de atributo o diseño por contrato para evitar esto? ¿No hay forma de decir:

public RoomName(NotNullOrEmptyString name) 
{ 

sin tener que crear realmente ese tipo?

+0

Puede encontrar este enlace en [Validación de argumentos utilizando atributos e interceptación de métodos] (http://www.codinginstinct.com/2008/05/argument- validation-using-attributes.html) útil – Joe

Respuesta

7

Puede hacerlo a través de la inyección de código con atributos.

Otra opción para ahorrar algo de tiempo de codificación, pero aún así darle mucho control, sería usar algo como CuttingEdge.Conditions. Esto proporciona una interfaz fluida para el chequeo de argumentos, por lo que puede escribir:

name.Requires().IsNotNull(); 
1

Aunque la pregunta ha sido contestada hace un tiempo, he estado pensando sobre el mismo problema últimamente. Los contratos de código formalizados (con verificación o verificación automática) parecen ser una buena idea, pero en general, su capacidad de verificación es bastante limitada, y para comprobaciones simples como la verificación de cadena vacía o nula, requieren el mismo código (o más)) que los cheques pasados ​​de moda.

Irónicamente, la mejor respuesta en mi opinión para la cadena de los casos es de hecho uno o dos clases que envuelven una cadena que se ha comprobado no ser nula, vacía o espacios en blanco, y pasa este caso en torno a:

public class NonEmptyString : IComparable<NonEmptyString>, ... 
{ 
    private readonly string _value; 

    public NonEmptyString(string value) 
    { 
     if (value == null) 
     { 
      throw new ArgumentNullException("value"); 
     } 
     if (value.Length == 0) 
     {     
      throw NewStringIsEmptyException("value"); 
     } 
     _value = value; 
    } 

    public string Value 
    { 
     get { return _value; } 
    } 

    ... 
} 

public class NonWhiteSpaceString : NonEmptyString 
{ 
    .... 
} 

Claro, que pasa alrededor de estos casos no le impide tener que comprobar si son nulos sí mismos, pero tiene grandes ventajas:

  • usted no tiene que comprobar en vacío o blanco- cadenas espaciales una y otra vez, que pueden ser propensas a errores en situaciones donde la cadena se pasa mucho
  • Como lo he hecho en mi implementación, buscar null es algo diferente a buscar un valor vacío (o un valor de espacio en blanco), porque desea arrojar una ArgumentNullException específica en el primer caso, y alguna ArgumentException en el segundo.
  • Señala claramente la restricción en el valor de la cadena, como se supone que debe hacer cualquier clase de ajuste. De hecho, si tiene una cadena que tiene alguna restricción y se transmite mucho, siempre recomiendo envolverla en una clase que encapsula la verificación y evita que el resto del código entre en problemas. Un buen ejemplo de esto son las cadenas que deben satisfacer una cierta expresión regular. Sin embargo, me estoy desviando de la pregunta aquí ...
+1

Creo que necesita agregar algún seguimiento del nombre del parámetro a su solución. Esto es porque a la mayoría le resultaría confuso si llamaras 'frob (string foo, string bar)' con 'frob (null," a value ")' y obtuvieras el mensaje de error 'System.ArgumentNullException: Value no puede ser nulo. Nombre del parámetro: value' en lugar de 'System.ArgumentNullException: el valor no puede ser nulo. Nombre del parámetro: foo' –