Esiste una best practice sull'uso dei due file di codice follower relativi alle eccezioni.Errore di stampa rispetto a Exception.getMessage
//code1
} catch (SomeException e) {
logger.error("Noinstance available!", e.getMessage());
}
//code2
} catch (SomeException e) {
logger.error("Noinstance available!", e);
}
Quando è necessario utilizzare il metodo getMessage di un'eccezione?
Il primo non viene compilato poiché il metodo error accetta un String come primo parametro e un Throwable come secondo parametro.
e.getMessage() non è un Throwable.
Il codice dovrebbe essere
} catch (SomeException e) {
// No stack trace
logger.error("Noinstance available! " + e.getMessage());
}
Rispetto
} catch (SomeException e) {
// Prints message and stack trace
logger.error("Noinstance available!", e);
}
Le prime stampe solo un messaggio. Il secondo stampa anche l'intera traccia dello stack.
Dipende dal contesto se è necessario stampare la traccia dello stack o meno.
Se si conosce già il motivo per cui è possibile lanciare un'eccezione, non è consigliabile stampare l'intera traccia dello stack.
Se non si sa, è meglio stampare l'intero tracciato per individuare facilmente l'errore.
Sto usando il logger sl4j e il mio codice1 compila. perché è quello – DesirePRG
Ok, le mie informazioni erano per log4j standard, ma il resto rimane valido –
Exception.printStackTrace() non deve essere utilizzato a meno che non si utilizzi ad esempio il debug.
Per la registrazione, è decisamente meglio utilizzare Exception.getMessage(). Si noti inoltre che molti framework di registrazione (ad esempio Log4j) accettano l'eccezione come argomento sul metodo di registrazione (ad esempio error()) e lo elabora da solo.
Dipende se è necessaria la traccia dello stack dell'eccezione originale (SomeException). Se sì, allora il codice 2 è l'opzione corretta qui. Si noti che è il modo più comune di gestire queste situazioni.
Se non si è interessati all'eccezione originale, è possibile utilizzare il codice 1 ma questo non è corretto. Perché il codice che hai inviato accetta il messaggio come argomento. Quindi il modo corretto è:
logger.error("Noinstance available! - reason:" + e.getMessage());
Questo prototipo è utile, quando si classifica eccezione in livello di Business e eccezione tecnico.
Per Eccezioni di livello aziendale, è sufficiente utilizzare il messaggio, collegandosi per analytics o potrebbe essere necessario visualizzare sullo schermo informazioni di significato (qualcosa non ha funzionato).
Per Eccezione tecnica, è meglio registrare l'errore con stacktrace, trovare il problema ed è facile eseguire il debug e risolvere.
Con stacktrace:
logger.error("Could not do XYZ because of: " + ex, ex);
Senza stacktrace:
logger.error("Could not do XYZ because of: " + ex);
Si può provare questo: -
logger.error(e.getMessage(), e);
restituisce il messaggio stringa di dettaglio di questo Throwable.
logger.error(e.getLocalizedMessage(),e);
Crea una descrizione localizzata di questo throwable. Le sottoclassi possono sovrascrivere questo metodo per produrre un messaggio specifico della locale. Per le sottoclassi che non sovrascrivono questo metodo, l'implementazione predefinita restituisce lo stesso risultato di getMessage().
Nel tuo caso e non è altro che l'oggetto d'eccezione ...
getLocalizedMessage() u bisogno di ignorare e dare il proprio messaggio cioè il significato per il messaggio localizzato.
Quasi tutto il tempo. A meno che tu non conosca il metodo SomeException e il metodo toString sovrascritto. E.getMessage() è il modo standard –
Se si registra solo il messaggio, non si ottiene una traccia di stack o l'eccezione nidificata dovrebbe essercene una. Registra l'eccezione ... –
@TheNeoNoirDeveloper: "Quasi sempre" cosa? Il primo? Preferisco non perdere le informazioni su da dove proviene l'eccezione, la sua causa, ecc. –