C# ¿qué tipo de excepción debo plantear?

Question

Actualmente estoy en un intento de captura encontrar si una propiedad se ha establecido correctamente para el valor bool que debería ser así ...

public void RunBusinessRule(MyCustomType customType) 
{ 
    try 
    { 
     if (customType.CustomBoolProperty == true) 
     { 
      DoSomething(); 
     } 
     else 
     { 
      throw new Exception("This is obviously false or possibly null lets throw up an error."); 
     } 
    } 
    catch(Exception) 
    { 
     throw; 
    } 
} 

Ahora el acuerdo con lanzar este error para mí es que soy utilizando el análisis fuente de Microsoft y me da un error que dice "CA2201: Microsoft.Usage: Object.RunBusinessRule (MyCustomType) crea una excepción de tipo 'Excepción', un tipo de excepción que no es lo suficientemente específico y nunca debe ser invocado por el código de usuario. Si se puede lanzar esta instancia de excepción, use un tipo de excepción diferente.

Soooo ¿Qué excepción debo arrojar que sea lo suficientemente específica para Microsoft .., por la circunstancia de arrojar un error sobre el manejo de la lógica de mi propia aplicación y cuándo quiero "lanzar".

Answer 1

ArgumentException 
InvalidOperationException 
FormatException 

El argumento de la transmisión no fue bueno.

Answer 2

ArgumentException ¿quizás?

También se pudo hacer una carcasa para InvalidOperationException.

Answer 3

¿Debería lanzar una excepción?

Tener un valor booleano falso no es exactamente una circunstancia excepcional.

EDITAR

Mi respuesta original era un poco escueta así que voy a elaborar ...

De su ejemplo, no está claro lo que los objetos reales, propiedades y métodos representan. Sin esta información, es difícil decir qué tipo de excepción, si corresponde, es apropiada.

por ejemplo, me gustaría considerar el siguiente un uso perfectamente válido de una excepción (y su código real bien podría ser algo como esto, pero no podemos decir por tu ejemplo):

public void UpdateMyCustomType(MyCustomType customType) 
{ 
    if (!customType.IsUpdateable) 
     throw new InvalidOperationException("Object is not updateable."); 

    // customType is updateable, so let's update it 
} 

Pero en el caso general, sin saber más acerca de su modelo de dominio, diría que algo como esto (un valor booleano falso) no es realmente excepcional.

Answer 4

Un ligero a un lado, pero se puede simplificar el código un poco ...

public void RunBusinessRule(MyCustomType customType) 
{ 
    if (customType.CustomBoolProperty == false) 
    { 
     throw new Exception("This is obviously false or possibly null lets throw up an error."); 
    } 

    DoSomething(); 
} 

En cuanto al tipo de excepción a tirar, podría considerar ApplicationException o InvalidOperationException, o puede definir su propio tipo de excepción.

Answer 5

Crea tu propia excepción extendiendo Exception. Por ejemplo: RuleViolationException

Answer 6

Haga su propia excepción personalizada extendiendo System.Exception y lance eso. Puede ponerse aún más loco y tener todo un árbol de tipos de excepción si lo desea.

Answer 7

Puede crear simplemente un ValidationException personalizado que solo se utiliza para la validación de su lógica de negocio. O puede crear una excepción de validación por separado para cada tipo de error de validación, aunque probablemente sea una sobrecarga.

Answer 8

sé que se trata de una pregunta lanzar una excepción, pero creo que sería más apropiado hacer una assertation aquí:

// Precondition: customType.CustomBoolProperty == true 
System.Diagnostics.Debug.Assert(customType.CustomBoolProperty) 
DoSomething(); 

Answer 9

excepción InvalidArgument está bien, pero mejor aún, un ApplicationException.

Answer 10

La respuesta aquí es que no debe arrojar ninguna excepción. ¿Por qué lanzar una excepción solo para atraparla de nuevo en un segundo y volver a lanzarla?

Answer 11

No es realmente lo que estaba pidiendo, pero hay un montón de gente que ya ha dado respuestas con las que estoy de acuerdo, pero también debe evitar el uso de catch (Exception ex).

Es una práctica mucho mejor tratar de detectar las Excepciones específicas que son posibles primero y, si es necesario, capturar la Excepción genérica. por ejemplo:

try{ 
    MyMethod(obj); 
}catch (NullReferenceException ne){ 
    //do something 
} 
catch(UnauthorizedAccessException uae){ 
    //do something else 
} 
catch(System.IO.IOException ioe){ 
    //do something else 
} 
catch(Exception){ 
    //do something else 
} 

Answer 12

Las otras respuestas están muy bien para la resolución rápida, pero lo ideal si usted sabe en tiempo de compilación que un determinado método no debe ser invocado usando ciertos parámetros, puede evitar que vuelva a suceder al heredar el tipo personalizado , lo instancia solo cuando ese bool personalizado es verdadero, y ahora su método se parece a.

public void RunBusinessRule(MyInheritedType inheritedObject) 
{ 
    //No need for checks, this is always the right type. 
    //As a matter of fact, RunBusinessRule might even belong to MyInheritedType. 
} 

Este es el I en SOLID.

Answer 13

Creo que debe evitar excepciones para la lógica del código.

que sugieren que modificar su método para devolver el resultado de su método como un tipo bool entonces puede decidir la forma adecuada de mostrar un mensaje de error al usuario en el momento de llamar al método:

public bool RunBusinessRule(MyCustomType customType) 
{ 
    try 
    { 
     if (customType.CustomBoolProperty == true) 
     { 
      DoSomething(); 
      return true; 
     } 

     return false; 
    } 
    catch(Exception) 
    { 
     throw; 
    } 
}