exception - sistema - omc
¿Debería una violación a las reglas comerciales arrojar una excepción? (14)
¿Debería una violación a las reglas comerciales arrojar una excepción?
¿Quiere decir, por ejemplo, que se supone que un valor está en el rango 0-99, pero de alguna manera terminó siendo 105?
Si proviene del usuario, es una cuestión de validación. Si se maneja usando excepciones o no depende de las expresiones idiomáticas de su idioma.
Si proviene de su almacén de datos, entonces sí, parece razonable lanzar una excepción. Significa que tiene datos erróneos y necesita descubrir cómo llegó allí y evitar que vuelva a suceder.
Como una vista alternativa a la mayoría de las respuestas ...
Puede ser útil arrojar excepciones desde la lógica de negocios, particularmente si son interrumpidas por una falla en la validación. Si esperas un objeto y obtienes un nulo, sugiere que algún problema ha eludido la detección en la interfaz de usuario (u otra interfaz). Puede ser completamente válido arrojar excepciones en este punto. De hecho, puede decidir colocar este tipo de validación en la lógica comercial cuando hay múltiples interfaces.
Lanzar excepciones en algunos idiomas / frameworks (estoy pensando en .NET) puede ser costoso, pero esto no debería preocuparte de inmediato. Significa que, según su nombre, se usan para circunstancias excepcionales y no como parte del flujo estándar de un programa. Ciertamente no deberías lanzar una excepción solo para salir de un método. También debería considerar una recuperación elegante donde sea posible que no incluya arrojar una excepción.
Entonces, resumiendo ... Depende ...
Debido a la forma en que hago mi validación y mi uso de LINQtoSQL para ORM, sí. Si una entidad no supera la validación de una regla comercial durante el método OnValidate, la única forma de notificar al código de llamada es emitir una excepción. En este caso, lanzo una DataValidationException personalizada. Al utilizar el método OnValidate, enganchar en una implementación de clase parcial de la entidad hace que sea posible para mí aplicar la validación en la actualización / inserción para que solo los datos válidos se guarden en la base de datos.
EDITAR Debo dejar en claro que normalmente hago la validación de la entrada del usuario en el cliente, por lo que la validación de la capa de persistencia suele ser más segura y rara vez falla. No manejo la validación del lado del cliente como excepciones, sino más bien con lógica condicional.
Depende de lo que sea la regla de negocio, IMO. Me atrevería a decir "generalmente no", pero lo vería caso por caso. No creo que haya una sola respuesta, ya que las diferentes reglas comerciales podrían justificarlo mientras que otras podrían no hacerlo.
No. Es parte de la lógica normal de manejo condicional en el programa (y a menudo solo una forma encubierta de error del usuario).
Normalmente pongo la condición en un objeto de especificación que implementa
bool IsVerfiedBy(T entity);
Para que pueda verificar la condición sin excepción.
Si hay un lugar en su código donde la especificación debe verificarse de antemano, puede lanzar una excepción porque este es un requisito previo de su función.
Por ejemplo, si su entidad debe estar en un estado específico antes de la persistencia, haga una excepción cuando la especificación no esté verificada, pero use la especificación antes de continuar para que la excepción no ocurra.
Realmente depende de qué es y dónde está.
Si se trata de algunos datos que provienen del usuario, entonces levand dijo que es una cuestión de validación. La validación puede aparecer tanto exitosa como fallida, ambas son opciones esperadas con claros escenarios de acción adicionales.
Si es algo así como los errores de ejecución del método, podría ser una mejor idea lanzar una excepción y detenerse justo antes de que se haga más daño (como por ejemplo, producir inconsistencias en la base de datos).
A menudo es una cuestión de perspectiva y el diseño de su aplicación.
Lanzar excepciones puede ser computacionalmente intensivo, están fuera de la norma. Por ejemplo, en .net tiene contadores de rendimiento que se incrementan, eso es una actividad pesada y, por lo tanto, no es algo que desee hacer en lugar de un simple condicional.
Primero, un par de citas del capítulo 18 de Microsoft .NET Framework Programming aplicado (página 402) por Jeffrey Richter :
"Otro error común es que una ''excepción'' identifica un ''error''".
"Una excepción es la violación de las suposiciones implícitas de una interfaz programática".
Si deduzco correctamente de su pregunta que una violación de una regla de negocios sería información que cae fuera de cierto rango (por ejemplo), este es un error que podría manejar con un condicional como lo sugirió "ahockley". Según la definición de una excepción de Richter, el uso apropiado de una excepción sería si su código no pudo recuperar una regla comercial del repositorio que está utilizando. Ser capaz de recuperar una regla de negocio sería una suposición implícita razonable para esa interfaz, por lo que debería lanzarse una excepción si se viola esta suposición.
Un buen ejemplo de la primera cita de Richter (¡excepción! = Error) es la excepción ThreadAbortException. Si llama a Response.Redirect (url) (en ASP.NET), se lanza una excepción ThreadAbortException aunque la redirección tenga éxito. ¿Por qué? La suposición implícita de la ejecución de la página ASP.NET es que una página se ejecutará por completo. Response.Redirect (url) viola esta suposición, de ahí la excepción.
Las reglas comerciales no deben arrojar una excepción, a menos que se utilicen para validar parámetros de alguna API (es decir, verificar la validez de las solicitudes) o en pruebas unitarias (es decir, usar reglas comerciales para simplificar las pruebas de la unidad .NET ).
Sin embargo, en general las reglas comerciales emiten mensajes de error y advertencia al alcance de la validación.
No Violar una regla de negocios es un asunto de NEGOCIO donde una excepción es técnica. La violación de una regla de negocios es algo que el sistema debería considerar como una operación normal y para la cual debería tener una respuesta programada, no una excepción.
Yo diría que no normalmente, pero no creo que puedas decir nunca.
Por ejemplo, depende de quién / qué maneja la regla fallida. Si se trata de una interfaz de usuario / usuario, entonces utilizaría la lógica condicional para abordar la falla de manera adecuada. Sin embargo, si se trata de una falla de regla empresarial en, por ejemplo, un proceso sin rostro que registra cualquier error en un registro de eventos que será supervisado por un recurso técnico, entonces una excepción puede ser tan apropiada. En este caso posterior, una excepción con un nombre apropiado puede ser tan útil como un mensaje muy formateado.
Las reglas comerciales podrían arrojar excepciones, pero no deberían.
Si tiene otra forma de comunicar información sobre errores de validación comunes y predecibles, debe usarla.
Hay una buena guía en el wiki para el libro. 97 Cosas que todo gerente de proyecto debe saber , en particular en el capítulo Distinguir las excepciones comerciales de las técnicas .
Por lo tanto, si su lenguaje de programación lo admite, lo mejor es crear clases de excepciones personalizadas para que su flujo de trabajo y su manejo puedan ser diferentes de las excepciones técnicas.