Quando registrare le eccezioni concatenate?

Question

Sono uno sviluppatore verde che sta cercando di ottenere un handle (har-har) sulla gestione degli errori in una grande applicazione java multistrato. Ci sono molte situazioni in cui credo che concatenare le eccezioni attraverso diversi livelli sia una buona idea; per esempio. quando un guasto nel chiamare fuori per qualche servizio esterno al livello più basso provoca problemi tutta la strada fino nella vista:

• Content X richiesto, ma l'utente non è autorizzato
  • causato da: Elenco dei autorizzate utenti è nullo
    • causati da: gestione utenti webservice risposto Bad richiesta- parametro foo deve essere formattato come 'xyz'

L'eccezione più importante, quella il cui stacktrace voglio veramente esaminare, è l'ultimo della catena; che ho fatto una cattiva richiesta e ho bisogno di correggere la formattazione di foo. Ma quando lascio che questa eccezione esploda attraverso i livelli, ben incatenata con eccezioni significative per ogni livello ... quando finalmente catturo e registro la cosa, il comportamento di registrazione predefinito mi mostra sempre dei dettagli sull'eccezione più esterna, e forse 5 righe di stacktrace della causa principale.

Questo mi fa venir voglia di registrare le eccezioni mentre accadono, E lasciarle esplodere, ma poi si finisce per loggare la maggior parte delle cose due volte; quando accadono e quando alla fine vengono catturati.

Qual è la migliore pratica qui?

Answer 1

Grande domanda, sono curioso di altre risposte che otterrete.

Tendo a prendere un approccio "più è meglio" e registro ad ogni passo del percorso. Questo fa grandi log? Sì, ma quando esegui il debug di un problema in una grande applicazione Java, sarai grato per ogni linea di log che hai. Esistono anche strumenti (come minimo il grep, awk, sed) per facilitare il filtraggio di file di grandi dimensioni.

Un'altra tecnica è quella di scrivere questo codice di registrazione, ma girarlo verso il basso (se stai usando qualcosa come log4j, al livello TRACE). In questo modo, se dovessi riscontrare un problema, potresti non avere i registri disponibili, ma è una modifica di una riga (per ridurre la soglia di registrazione) e inizierai a generare una grande quantità di dati per il debug.

In tandem con la tecnica precedente, la maggior parte delle librerie di registrazione (di nuovo sto ricadendo sulle mie conoscenze di log4j qui) consentono di ottimizzare i livelli di registro di diversi pacchetti java. Ciò significa che è possibile scrivere tutte queste righe di registro "catch and rethrow" come traccia e abbassare la registrazione dei pacchetti di livello inferiore a WARN mentre si mantengono i pacchetti di livello superiore a DEBUG o TRACE.

Answer 2

Consiglierei un approccio diverso per la gestione delle eccezioni. Al livello più alto dell'applicazione (come il punto di ingresso della richiesta) crea un blocco catch try per chiamare qualsiasi eccezione di runtime. E 'preferibile che hai 2 blocchi catch: - per la vostra specifica applicazione (business class) eccezioni - per il resto (eccezione)

Come si può vedere youl'l bisogno di presentarvi proprio tipo di eccezione che si estende creare diverse eccezioni per scopi diversi. Ad esempio, puoi creare un'eccezione personalizzata per ogni livello dell'applicazione, per ogni integrarion ecc.Utilizza le eccezioni non controllate poiché verranno gestite tutte al livello più alto. Quando si verifica una situazione eccezionale (cattura di un'eccezione di basso livello), è necessario: - Inserire una descrizione associata al contesto aziendale (ad esempio "Impossibile caricare i dati dell'account da DB" - Aggiungere la descrizione dell'eccezione originale (ad esempio "Originale errore: connessione a DB non riuscita ") - Passa l'eccezione originale alla tua eccezione per non perdere la traccia - Getta e dimentica. In altre parole blocco catch di livello superiore è responsabile di gestirlo appropriatamente (rollback di una transazione, mostra messaggio di errore o qualsiasi altra cosa tu abbia bisogno