Perché "log and throw" è considerato un anti-pattern? [chiuso]

Questa domanda è stata innescata da una discussione su questo articolo , in cui non ho ricevuto nessuna buona risposta.

Perché registrare la tua eccezione e poi rilanciarla (preservando la traccia dello stack originale ovviamente) dovrebbe essere una cattiva idea se non puoi gestirla diversamente?

Presumo che la risposta sia in gran parte perché lo prendi se non puoi gestirlo? Perché non lasciare che chiunque possa gestirlo (o chiunque non abbia altra scelta che gestirlo) lo registri, se ritengono che sia degno di nota?

Se lo prendi, lo registri e lo rilanci, non c'è modo per il codice upstream di sapere che hai già registrato l'eccezione, quindi la stessa eccezione potrebbe essere registrata due volte. O peggio, se tutto il codice a monte segue lo stesso schema, l'eccezione potrebbe essere registrata un numero arbitrario di volte, una volta per ogni livello del codice che decide di catturarlo, registrarlo e quindi lanciarlo di nuovo.

Inoltre, alcuni potrebbero obiettare che poiché lanciare e catturare eccezioni sono operazioni relativamente costose, tutto questo catturare e rilanciare non aiuta le prestazioni di runtime. Né aiuta il tuo codice in termini di concisione o manutenibilità.

Log-and-throw è un buon modello se e solo se l'entità che cattura e rilancia l'eccezione ha motivo di credere che contenga informazioni che non verranno registrate più in alto nello stack di chiamate, almeno non nel modo più desiderato. Un paio di ragioni per cui ciò può verificarsi:

1. L'eccezione può essere rilevata e lanciata di nuovo al limite del livello dell'applicazione e può contenere informazioni privilegiate. Sarebbe negativo per un livello di database consentire un'eccezione, ad esempio "Tentativo di aggiungere la chiave duplicata 'fnord' al campo 'utenti'" per raggiungere il livello dell'applicazione esterno (che potrebbe a sua volta esporlo a un utente), ma potrebbe essere utile per le parti interne del database per lanciare un'eccezione di questo tipo e l'interfaccia dell'applicazione per catturarla, registrarla in modo sicuro e rilanciare un'eccezione un po 'meno descrittiva.
2. L'eccezione potrebbe essere quella che il livello esterno probabilmente si aspetterebbe di gestire senza registrazione, ma il livello interno potrebbe conoscere qualcosa che il livello esterno non fa, il che suggerirebbe che la registrazione potrebbe essere utile. Ad esempio, un livello di applicazione intermedio potrebbe essere programmato per provare a connettersi a un server e, se non funziona, provarne un altro. Inondare il registro dell'applicazione con messaggi di "connessione non riuscita" mentre un server è inattivo per manutenzione potrebbe non essere utile, soprattutto perché, dal punto di vista dell'applicazione, tutto ha funzionato correttamente. Può essere utile inoltrare informazioni sull'errore di connessione a una risorsa di logging associata ai server, che potrebbe quindi filtrare i log in modo da produrre un report di quando il server è andato su e giù, invece di un log di ogni singolo tentativo di connessione .

Immagino che il motivo più semplice sia che in genere avresti un singolo gestore di primo livello che lo fa per te, quindi non è necessario inquinare il codice con questa gestione delle eccezioni.

L'argomento trasversale delle preoccupazioni è fondamentalmente che è una perdita di tempo a gestire gli errori che non ti riguardano. Molto meglio lasciare che l'errore si riempia di bolle fino a quando non si trova un gestore appropriato.

Secondo me, l'unica volta in cui dovresti catturare un'eccezione è quando puoi fare qualcosa di utile con i risultati. Catturare semplicemente il log non è utile, perché potresti centralizzare quel lavoro più in alto.

Il log and throw dell'IMO è una chiara violazione del principio della minima sorpresa.

Se l'eccezione viene gestita correttamente più in alto nello stack di chiamate, potrebbe non valere affatto la pena di una voce di registro degli errori. E poi è fonte di confusione trovare una voce di registro degli errori.