2010-04-27 11 views
6

Tengo un sistema en el que el ID de empleado siempre debe existir a menos que haya algún problema subyacente.C# Throw Exception on use ¿Assert?

La forma en que lo veo, es que tengo dos opciones para comprobar este código:

1:

public void GetEmployee(Employee employee) 
{ 
    bool exists = EmployeeRepository.VerifyIdExists(Employee.Id); 
    if (!exists) 
    { 
    throw new Exception("Id does not exist"); 
    } 
}  

o 2:

public void GetEmployee(Employee employee) 
{ 
    EmployeeRepository.AssertIfNotFound(Employee.Id); 
} 

es la opción # 2 aceptable en el lenguaje C#?

me gusta porque es ordenada en la que no me gusta mirar a "arrojar nueva Excepción (" bla bla bla ") escribir mensajes OutSite el ámbito de la clase.

+1

¿Por qué no hacer que su método VerifyIdExists genere la excepción en su nombre? – Tejs

+0

No creo que haya nada de malo en lo que tienes, excepto en mi humilde opinión, cambiaría el nombre a ThrowIfNotFound. Considero que esto es algo que desea incluir en la compilación de lanzamiento, así como su compilación de depuración. –

Respuesta

3

Depende de lo que entendemos por Assert.

Puede usar Debug.Assert (o Trace.Assert si quiere que también funcione en modo de lanzamiento). Sin embargo, esto no es útil porque detiene el programa y muestra un cuadro de diálogo hasta que el usuario presiona algo. Esto no es así bueno para un sistema no supervisado. Por lo tanto, recomiendo lanzar en su lugar en la mayoría de los casos, ya que puede decidir cómo quiere reaccionar ante el error: detenga el programa o simplemente inicie sesión y trate de continuar.

Pero si suponemos que su método Assert comprueba su argumento y posiblemente arroja una excepción, entonces sí, creo que es una buena forma de hacerlo.

De hecho, para tomar un ejemplo, en Jon Skeet's morelinq se usan ambos métodos. Por ejemplo here:

public static IEnumerable<TSource> AssertCount<TSource>(
    this IEnumerable<TSource> source, 
    int count, 
    Func<int, int, Exception> errorSelector) 
{ 
    source.ThrowIfNull("source"); 
    if (count < 0) throw new ArgumentException(null, "count"); 
    errorSelector.ThrowIfNull("errorSelector"); 

    return AssertCountImpl(source, count, errorSelector); 
} 
+1

Sí. My Assert es para "Lanzar una excepción". Gracias j. – guazz

+0

@guazz: La primera vez que leí tu pregunta pensé que estabas comparando tirar con afirmación, y al mirar las otras respuestas y votos, también lo hicieron todos los demás. Es posible que desee volver a redactar su pregunta para que quede más claro. –

+0

método de extensión para la excepción de argumento? –

1

Use excepciones, es lo que ellos están allí para - circunstancias excepcionales. Todas las bibliotecas .NET estándar usan este método para manejar tales circunstancias, así que toma sus señales de Microsoft.

5

Como regla general, solo debe lanzar excepciones en circunstancias excepcionales . Desde esta circunstancia, lanzar una excepción es lo correcto.

0

La idea detrás de las aserciones, como siempre las he usado, es que son comentarios instantáneos cuando se ejecuta una compilación de depuración. Algo en la cara de que algo sucedió. O registrado en el archivo si la aplicación está configurada de esa manera.

Las excepciones se usan para manejar un comportamiento excepcional, como se indicó anteriormente.

Lo que hago, especialmente temprano en el ciclo de proyectos de vida podría ser algo como:

public void GetEmployee(Employee employee) 
{ 
    bool exists = EmployeeRepository.VerifyIdExists(Employee.Id); 
    Debug.Assert(exists, "employee does not exist for id: " + Employee.Id); 
    if (!exists) 
    { 
    throw new Exception("Id does not exist); 
    } 
} 

Quizás refractoring la Debug.Assert una vez que los contratiempos iniciales se tratan.