¿Por qué se considera que “log and throw” es un anti-patrón? [cerrado]

Esta pregunta fue provocada por una discusión sobre este artículo , donde no recibí ninguna buena respuesta.

¿Por qué debería ser una mala idea registrar su excepción y luego volver a lanzarla (conservando el seguimiento de la pila original, por supuesto) si no puede manejarlo de otra manera?

Supongo que la respuesta se debe en gran parte a que, ¿por qué lo capta si no puede manejarlo? ¿Por qué no dejar que quien pueda manejarlo (o quien no tenga más remedio que manejarlo) lo registre, si sienten que vale la pena registrarlo?

Si lo detecta, lo registra y lo vuelve a lanzar, entonces no hay forma de que el código ascendente sepa que ya ha registrado la excepción, por lo que la misma excepción podría registrarse dos veces. O peor aún, si todo el código ascendente sigue este mismo patrón, la excepción podría registrarse un número arbitrario de veces, una por cada nivel del código que decida capturarlo, registrarlo y luego lanzarlo nuevamente.

También algunos podrían argumentar que dado que lanzar y capturar excepciones son operaciones relativamente costosas, toda esta captura y relanzamiento no está ayudando a su rendimiento en tiempo de ejecución. Tampoco ayuda a su código en términos de concisión o mantenibilidad.

Log-and-throw es un buen patrón si la entidad que captura y vuelve a generar la excepción tiene motivos para creer que contiene información que no se registrará más arriba en la pila de llamadas, al menos no de la manera más deseada. Algunas razones por las que esto puede ocurrir:

1. La excepción se puede detectar y volver a lanzar en un límite de la capa de aplicación y puede contener información privilegiada. Sería malo que una capa de base de datos permitiera una excepción que dijera, por ejemplo, "Intente agregar la clave duplicada 'fnord' al campo 'usuarios'" para llegar a la capa externa de la aplicación (que a su vez podría exponerla a un usuario), pero podría ser útil para las partes internas de la base de datos para lanzar una excepción de este tipo y la interfaz de la aplicación para detectarla, registrarla de forma segura y volver a generar una excepción algo menos descriptiva.
2. La excepción puede ser una que la capa externa probablemente esperaría manejar sin registrar, pero la capa interna puede saber algo que la capa externa no sabe, lo que sugeriría que el registro puede ser útil. Como ejemplo burdo, una capa de aplicación intermedia podría estar programada para intentar conectarse a un servidor y, si eso no funciona, pruebe con otro. Inundar el registro de la aplicación con mensajes de 'conexión fallida' mientras un servidor está inactivo por mantenimiento puede no ser útil, especialmente porque, desde la perspectiva de la aplicación, todo funcionó bien. Puede ser útil reenviar información sobre la falla de conexión a un recurso de registro asociado con los servidores, que luego podría filtrar los registros para producir un informe de cuándo el servidor subió y bajó, en lugar de un registro de cada intento de conexión. .

Supongo que la razón más simple es que normalmente tendrías un solo controlador de nivel superior haciendo esto por ti, por lo que no es necesario contaminar el código con este manejo de excepciones.

El argumento de las preocupaciones transversales es básicamente que es una pérdida de tiempo manejar errores que no le conciernen. Es mucho mejor dejar que el error aumente en la pila de llamadas hasta que se pueda encontrar un controlador adecuado.

En mi opinión, la única vez que debería detectar una excepción es cuando puede hacer algo útil con los resultados. Capturar simplemente para registrar no es útil, porque podría centralizar ese trabajo más arriba.

El registro y lanzamiento de la OMI es una clara violación del principio de la menor sorpresa.

Si la excepción se maneja correctamente más arriba en la pila de llamadas, es posible que no valga la pena una entrada en el registro de errores. Y luego es confuso encontrar una entrada de registro de errores.