Por que “log e jogar” é considerado um anti-padrão? [fechadas]

Esta questão foi gerada por uma discussão em torno deste artigo , onde não recebi nenhuma boa resposta.

Por que registrar sua exceção e, em seguida, lançá-la novamente (preservando o rastreamento de pilha original, é claro) seria uma má ideia se você não pode lidar com isso de outra forma?

Presumo que a resposta seja em grande parte porque você está pegando se não consegue lidar com isso? Por que não deixar quem pode lidar com isso (ou quem fica sem escolha a não ser lidar com isso) registrá-lo, se eles acham que é digno de log?

Se você capturá-lo, registrá-lo e lançá-lo novamente, não haverá como o código upstream saber que você já registrou a exceção e, portanto, a mesma exceção pode ser registrada duas vezes. Ou pior, se todo o código upstream seguir o mesmo padrão, a exceção pode ser registrada um número arbitrário de vezes, uma para cada nível no código que decide capturá-lo, registrá-lo e lançá-lo novamente.

Além disso, alguns podem argumentar que, como lançar e capturar exceções são operações relativamente caras, toda essa captura e relançamento não está ajudando no desempenho do tempo de execução. Nem está ajudando seu código em termos de concisão ou facilidade de manutenção.

Log-and-throw é um bom padrão se a entidade que captura e relança a exceção tem motivos para acreditar que ela contém informações que não serão registradas posteriormente na pilha de chamadas - pelo menos não da maneira mais desejada. Alguns motivos pelos quais isso pode ocorrer:

1. A exceção pode ser capturada e relançada em um limite da camada de aplicativo e pode conter informações privilegiadas. Seria ruim para uma camada de banco de dados permitir uma exceção dizendo, por exemplo, "Tentativa de adicionar chave duplicada 'fnord' ao campo 'usuários'" para alcançar a camada de aplicativo externa (que por sua vez pode expô-la a um usuário), mas pode ser útil para partes internas do banco de dados para lançar tal exceção e a interface do aplicativo para capturá-la, registrá-la com segurança e relançar uma exceção um pouco menos descritiva.
2. A exceção pode ser aquela que a camada externa provavelmente espera controlar sem o registro, mas a camada interna pode saber algo que a camada externa não sabe, o que sugere que o registro pode ser útil. Como um exemplo bruto, uma camada de aplicativo do meio pode ser programada para tentar se conectar a um servidor e, se isso não funcionar, tente outro. Inundar o log do aplicativo com mensagens de 'falha de conexão' enquanto um servidor está fora do ar para manutenção pode não ser útil, especialmente porque - da perspectiva do aplicativo, tudo funcionou bem. Pode ser útil encaminhar informações sobre a falha de conexão para um recurso de registro associado a servidores, que poderia filtrar os registros de modo a produzir um relatório de quando o servidor foi ativado e desativado, em oposição a um registro de cada tentativa de conexão .

Eu acho que o motivo mais simples é que você normalmente teria um único manipulador de nível superior fazendo isso para você, então não há necessidade de poluir o código com esse tratamento de exceção.

O argumento das preocupações transversais é basicamente que é uma perda de tempo lidar com erros que não dizem respeito a você. Muito melhor deixar o erro borbulhar na pilha de chamadas até que um manipulador apropriado seja encontrado.

Em minha opinião, a única vez em que você deve capturar uma exceção é quando pode fazer algo útil com os resultados. Pegar simplesmente para registrar não é útil, porque você poderia centralizar esse trabalho mais adiante.

O registro e lançamento da IMO é uma violação clara do Princípio da Menor Surpresa.

Se a exceção for tratada adequadamente mais acima na pilha de chamadas, pode não valer a pena uma entrada de log de erros. E então é confuso encontrar uma entrada de log de erro.