tipos - C#¿qué tipo de excepción debería plantear?

que son excepciones en c#

Question

Actualmente estoy en un try catch finding si una propiedad se ha configurado correctamente al 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 trato con arrojar este error para mí es que estoy usando 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 ''Exception'', un tipo de excepción que no es lo suficientemente específico y nunca debería ser invocado por el código del usuario. Si se puede lanzar esta instancia de excepción, use un tipo de excepción diferente.

Entonces, ¿qué excepción debería arrojar que sería lo suficientemente específico 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

¿Deberías lanzar una excepción?

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

EDITAR

Mi respuesta original fue un poco escueta, así que elaboraré ...

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

Por ejemplo, considero que el siguiente es un uso perfectamente válido de una excepción (y su código real bien podría parecerse a esto, pero no podemos decir por su 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 2

Crea tu propia excepción extendiendo Exception . Ejemplo: RuleViolationException

Answer 3

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

Answer 4

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

Answer 5

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

Answer 6

No es realmente lo que estaba pidiendo, pero hay muchas personas que ya dieron respuestas con las que estoy de acuerdo, pero también deberían evitar el uso de capturas (Excepción 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. p.ej:

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 7

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

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

Answer 8

Solo podría crear una ValidationException personalizada que solo se use para la validación de su lógica de negocios. 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 9

Un pequeño aparte, pero podrías simplificar tu 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 lanzar, puede considerar ApplicationException o InvalidOperationException , o podría definir su propio tipo de excepción.

Answer 10

ArgumentException tal vez?

También podría hacerse un caso para InvalidOperationException .

Answer 11

ArgumentException
InvalidOperationException
FormatException

La discusión aprobada no fue buena.

Answer 12

Las otras respuestas están bien para una resolución rápida, pero idealmente, si sabe en tiempo de compilación que un método determinado nunca debe invocarse utilizando ciertos parámetros, puede evitar que eso suceda heredando su tipo personalizado, instanciando solo cuando ese bool personalizado es cierto, y ahora su método se parece.

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 Yo en SOLIDO .

Answer 13

Creo que deberías evitar excepciones para la lógica del código.

Le sugiero que modifique su método para devolver el resultado de su método como un tipo bool luego 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;
}
}