Recorte la misma excepción para proporcionar más información

7

¿Es una buena práctica volver a emitir la misma excepción para proporcionar información más específica? Por ejemplo:

var sitemap = "a string containing an XML document";
try {
   // throw InvalidXmlException if the document is not well formed
   parse(sitemap);
} catch (InvalidXmlException e) {
   throw new InvalidXmlException("The sitemap is not well formed: " + e.getMessage());
}
    
pregunta Cequiel 01.04.2015 - 22:04

5 respuestas

22

Proporcionar más información de contexto siempre es bueno. Pero hay un problema en el código que quería señalar (quizás un problema con la API, la clase de excepción subyacente). No estás pasando la causa raíz. No agregue e.getMessage () puede ser redundante. En su lugar, establece la causa raíz como esta

catch(SameExceptionClass e) {
    throw new SameExceptionClass("Some more Details", e);
}

Cuando se imprima esta excepción, contendrá su mensaje de e y los detalles adicionales que acaba de agregar. Si su clase de excepción no acepta la causa raíz, considere agregar un constructor que pueda aceptarlo. No proporcionar la causa raíz conduce a problemas relacionados con las excepciones "tragadas", donde no sabrá el punto real donde ocurrió la excepción original.

Pero sí, haga esto SOLAMENTE si cree que agregará más valor o más información de contexto en su nueva excepción.

    
respondido por el Yazad Khambata 01.04.2015 - 22:53
3

En general, la regla para las excepciones es, no cree un nuevo tipo de excepción y no vuelva a lanzar, a menos que esté seguro de que la persona que llama podrá hacer algo diferente con la nueva información que proporcione ( es decir, está proporcionando más información, como un mejor mensaje de error, o proporciona información para recuperar).

    
respondido por el Frank Hileman 01.04.2015 - 22:22
2

Aquí hay algo más que nadie ha mencionado aún: Abstracción . Tal vez lo más importante, fugas ¿abstracciones?

¿Tiene sentido permitir que su DataService lance una excepción de IO o base de datos? Yo diría que no, porque "filtra" la implementación subyacente al código del cliente. A su FooController no le debe importar si DataService está hablando con una base de datos o un sistema de archivos. Todo lo que necesita saber es que los datos que solicitó no se pudieron recuperar. Entonces sí. Vuelva a lanzar la excepción y agregue la información adicional (preservando adecuadamente el seguimiento de la pila) en el nivel adecuado de abstracción. En el ejemplo que proporcioné, en el nivel de DataService .

    
respondido por el RubberDuck 01.04.2015 - 23:21
1

Depende

Si su método está haciendo algo que será visible para el usuario final, la seguridad se convierte en una preocupación. Nunca debe devolver excepciones de bajo nivel al usuario en sistemas distribuidos.

Su declaración catch () debe encapsular el error de bajo nivel y solo escribirlo en un (más) mecanismo de registro seguro. Una que solo sea fácilmente accesible para el personal de soporte, no para el público en general.

Luego, crea y lanza un nuevo tipo de excepción genérico que le diga al usuario lo suficiente como para que pueda reportarlo de manera inteligente, pero no les da las claves del reino.

Para todas las demás excepciones, generalmente es mejor detectar la excepción en el punto en que realmente se pueda manejar.

Por ejemplo: si tiene una clase de negocios que llama a varias clases de datos, la clase de negocios puede ser más adecuada para manejar cualquier excepción de datos (es decir, darles contexto en el gran esquema de las cosas). Por lo tanto, no captar en absoluto las clases de datos.

Su kilometraje puede variar.

    
respondido por el Worrystone 06.04.2015 - 22:29
0

A menudo, el seguimiento de la pila en una excepción no tiene ningún valor y, en tales casos, no se hace daño al lanzar una nueva excepción.

Si no sabe lo que sucedió, por supuesto, retenga todos los datos que pueda para fines de depuración. Sin embargo, en el código bien escrito habrá pocas excepciones de este tipo, la mayoría de las excepciones serán porque el programa es una víctima de fuerzas externas. Si sabe cuál es la fuerza externa que causó el problema, lo más informativo es informarle al usuario.

Si sabe que no pudo encontrar el trabajo que acaba de decirle, ¿por qué le importa lo que estaba ejecutando? La información importante es que el trabajo no fue encontrado. (Tengo en mente un caso donde cada trabajo tiene un directorio con algunos megabytes de datos que no están en la base de datos).

    
respondido por el Loren Pechtel 06.04.2015 - 22:40

Lea otras preguntas en las etiquetas