precondiciones y excepciones

Question

Suponga que tiene un método con algunas condiciones previas y posteriores. ¿Está bien crear una clase de excepción para cada condición previa que no se cumple? Por ejemplo: No lograr pre1 significa lanzar una instancia notPre1Exception.

Answer 1

Sí y no.

Sí: violar una condición previa es ciertamente un momento apropiado para lanzar una excepción. Lanzar una excepción más específica facilitará la captura de esa excepción específica.

No: declarar una nueva clase de excepción para cada condición previa en su programa / API parece exagerado. Esto podría resultar en cientos o miles de excepciones eventualmente. Esto parece un desperdicio tanto mental como computacionalmente.

Recomendaría lanzar excepciones para violaciones de precondición. Sin embargo, no recomendaría definir una nueva excepción para cada condición previa. En cambio, recomendaría crear clases más amplias de excepciones que cubran un tipo específico de violación de precondición, en lugar de una violación de precondición específica. (También recomendaría usar excepciones existentes donde encajen bien).

Answer 2

¿Por qué no querrías definir PreconditionFailedException (condición previa de cadena)? Lanzar un tipo de excepción diferente para cada condición previa fallida es excesivo.

Answer 3

Una condición previa fallida debería generar una AssertException, o algo similar. Antes de invocar un método, se debe cumplir su condición previa. Si la persona que llama no hace esta comprobación, es un error en el programa o un uso incorrecto del método (API).

Answer 4

Solo si no se cumplen las condiciones previas sería una rara excepción .

Answer 5

Suena como un uso útil de excepciones para mí. Ciertamente permite un registro y una depuración más específicos que un simple "precondición fallida" general, aunque también podría tener una sola excepción de "precondición fallida" y poner qué precondiciones han fallado en el mensaje de excepción.

Answer 6

Creo que está bien crear una excepción diferente para todas sus excepciones siempre que planee usarlas y manejarlas.

He descubierto que cuanto mejor sea el manejo de errores / excepciones, más fácil será depurar el software en las etapas posteriores.

Por ejemplo: si tiene un excpeitón genérico para manejar todas las entradas incorrectas, debe ver todo lo que se pasó al método si hay un error. Si tiene una idea de todos los tipos de malas condiciones, sabrá exactamente dónde buscar.

Answer 7

Me parece posible, pero si quieres continuar con esta forma de lidiar con las condiciones previas, terminarás con N clases de excepción por método de clase. Parece un crecimiento explosivo de clases 'no funcionales'.

Siempre me gustó el código donde la funcionalidad 'núcleo' no manejaba la violación de las condiciones previas (aparte de afirmarlas, ¡una gran ayuda!). Este código se puede incluir en un "verificador de precondiciones", que sí arroja excepciones o notifica la no satisfacción de lo contrario.

Answer 8

Como una forma muy general de determinar si alguna vez debe crear una clase o no (y una excepción es una clase), debe determinar si hay algún código que haga que esta clase sea única de todas las otras clases (en este caso excepciones).

Si no, simplemente establecería la cadena en la excepción y lo llamaría un día. Si está ejecutando código en su excepción (quizás un mecanismo de recuperación genérico que puede manejar múltiples situaciones llamando a exception.resolve () o algo así), entonces podría ser útil.

Me doy cuenta de que las excepciones no siempre siguen esta regla, pero creo que es más o menos porque las excepciones proporcionadas por el lenguaje no pueden tener ninguna lógica comercial (porque no conocen el negocio, las bibliotecas siempre tienden a estar llenos de excepciones a las reglas de OO)

Answer 9

Creo que Ben está en el blanco aquí. ¿De qué sirve lanzar diferentes excepciones si no las vas a atrapar? Si realmente quieres lanzar una diferente, al menos tendría una común '' PreconditionFailedException '' clase base de la que todos derivan, y trata de organizarlos en algún tipo de heirachy para que puedas atrapar grupos de ellos. Personalmente, no tendría diferentes y solo tengo una excepción común que arrojas con los detalles del fallo en cada uno.

Answer 10

No, no debe crear una excepción específica para cada condición previa porque irá en contra de los principios del Diseño por Contrato.

Los corolarios de la implementación de condiciones previas es que deben ser parte de la documentación y que debe proporcionar los métodos necesarios para que la persona que llama verifique que todas las condiciones previas sean válidas. (es decir, si la ejecución de un método depende del estado de un objeto, el método para verificar el estado debe estar disponible para la persona que llama).

Entonces, la persona que llama debe poder verificar si se cumplen todos los requisitos previos antes de llamar a su método.

La implementación de excepciones específicas para cada pre-condición violada podría / podría alentar a la persona que llama a usar el patrón try / catch alrededor de la llamada al método, lo que está en contradicción con la filosofía del Diseño por Contrato.

Answer 11

Yo diría que está bien siempre y cuando se hagan excepciones no verificadas (subclase de RuntimeException en Java). Sin embargo, en Java es mejor usar solo aserciones.

Answer 12

Si hace esto, asegúrese de que todos hereden de otra excepción personalizada común.