¿Sigue siendo un antipatrón si registramos un mensaje de excepción y lanzamos una excepción diferente?

18

Nuestra aplicación web está utilizando un ExceptionMapperpara asignar algunas excepciones Response. Registramos los mensajes de excepción antes de lanzar una nueva excepción de la siguiente manera: 

catch (SomeException ex) {
  LOG.error(ex.getMessage());
  throw new MyException(ex.getMessage());
}

No estamos volviendo a lanzar la misma excepción , por lo que mi pregunta es si esto se consideraría un antipatrón Log and Throw . Y por lo tanto, sería mejor eliminar el registro en lugares similares y moverlos a varias ExceptionMapperclases de la siguiente manera:

@Provider
public class MyExceptionMapper implements ExceptionMapper<MyException> {

  // bla bla 

  @Override
  public Response toResponse(final MyException ex) {
    LOG.error(ex.getMessage());
    return Response.status(400).entity("something").build();
  }
}
java anti-patterns Diyarbakir
fuente
3
Te detendría tan pronto como inicies sesión ex.getMessage(), eso ya está mal.
biziclop
1
posible duplicado de ¿Debería informar el mensaje de texto de excepciones?
Discutible, informar el texto del mensaje de excepciones siempre es una mala idea .
En mi opinión, no es justo no mencionar en absoluto que se trata de un servicio web. Eso realmente cambia las reglas del juego, porque, por ejemplo, solo usar mecanismos de manejo de excepciones regulares puede ser un riesgo de seguridad; no desea que se envíen todas y cada una de las excepciones en una respuesta de error 500, que debe verificarse y filtrarse. El registro agresivo sobre el terreno también es mucho más común cuando se trata de sistemas que tienen clientes externos que lo invocan directamente. El registro de los seguimientos de pila en las llamadas de servicio que se invocan repetidamente puede ocasionar problemas de rendimiento y tamaños de archivos de registro inmanejables.
@Gimby En este caso, OP no envía ningún detalle de error en la respuesta (probablemente un contenido repetitivo de "error ocurrido"). Además, ¿cómo diagnostica un problema sin un stacktrace? Los registradores rodantes se ocupan habitualmente del tamaño de almacenamiento y los datos de registro son vergonzosamente comprimibles.
Marko Topolnik

Respuestas:

36

Su código en realidad no tiene uno, sino tres antipatrones:

  1. iniciar sesión y volver a lanzar;
  2. volver a lanzar sin envolver la causa original;
  3. registre solo el mensaje y no el stacktrace (este es el peor).

Si siguió la mejor práctica para:

  1. no atrapar en absoluto (deje que la excepción se propague por sí sola);
  2. si se ve obligado a atrapar una excepción marcada, envuélvala sin marcar y vuelva a lanzarla;
  3. nunca registre nada excepto en el nivel superior;
  4. registrar toda la excepción stacktrace con log.error("Error occurred", e);

entonces no enfrentaría ningún dilema, incluido el actual, porque el seguimiento de pila registrado también incluiría todas las excepciones envueltas.

Marko Topolnik
fuente