Drukowanie wyjątku kontra wyjątek.getMessage

Question

Czy istnieje najlepsza praktyka w używaniu następujących dwóch fragmentów kodu dotyczących wyjątków.

//code1 

} catch (SomeException e) { 
    logger.error("Noinstance available!", e.getMessage()); 
} 

//code2 
} catch (SomeException e) { 
    logger.error("Noinstance available!", e); 
} 

Kiedy należy użyć metody getMessage wyjątku?

Answer 1

Pierwsza nie jest kompilowana, ponieważ metoda error przyjmuje jako pierwszy parametr String a drugi jako Throwable.

e.getMessage() nie jest Throwable.

Kod powinien być

} catch (SomeException e) { 
    // No stack trace 
    logger.error("Noinstance available! " + e.getMessage()); 
} 

porównaniu z

} catch (SomeException e) { 
    // Prints message and stack trace 
    logger.error("Noinstance available!", e); 
} 

Pierwsze drukuje tylko wiadomość. Drugi drukuje również cały ślad stosu.

Zależy od kontekstu, czy konieczne jest wydrukowanie śledzenia stosu, czy nie.

Jeśli wiesz już, dlaczego można rzucić wyjątek, nie jest dobrym pomysłem wydrukowanie całego śladu stosu.

Jeśli nie wiesz, lepiej wydrukować cały ciąg śledzenia, aby łatwo znaleźć błąd. Nie należy używać

Answer 2

Exception.printStackTrace(), chyba że masz na przykład debugowanie.

Do rejestrowania zdecydowanie lepszym rozwiązaniem jest użycie Exception.getMessage(). Zwróć też uwagę, że wiele frameworków do logowania (na przykład Log4j) akceptuje wyjątek self jako argument w metodzie rejestrowania (na przykład error()) i sam je wykonuje.

Answer 3

To zależy, czy potrzebny jest ślad stosu oryginalnego wyjątku (SomeException). Jeśli tak, to kod2 jest tutaj poprawną opcją. Zauważ, że jest to bardziej powszechny sposób radzenia sobie z takimi sytuacjami.

Jeśli nie interesuje Cię pierwotny wyjątek, możesz użyć kodu1, ale ten jest nieprawidłowy. Ponieważ kod, który wysłałeś, przyjmuje wiadomość jako argument. Tak poprawny sposób to:

logger.error("Noinstance available! - reason:" + e.getMessage()); 

Answer 4

Prototyp ten jest przydatny, kiedy klasyfikować wyjątek w biznesowym poziomie i wyjątkiem Technicznej.

W przypadku wyjątku dotyczącego poziomu biznesowego wystarczy użyć komunikatu, logując się do usługi analytics lub może być wyświetlany na ekranie informacja o znaczeniu (coś nie działa).

W przypadku wyjątku technicznego lepiej jest zarejestrować błąd za pomocą stosu, aby znaleźć problem i łatwo go usunąć i rozwiązać.

Answer 5

Z stacktrace:

logger.error("Could not do XYZ because of: " + ex, ex); 

Bez stacktrace:

logger.error("Could not do XYZ because of: " + ex); 

Answer 6

Można spróbować to: -

logger.error(e.getMessage(), e); 

Zwraca wiadomość ciąg szczegółowości tego Throwable.

logger.error(e.getLocalizedMessage(),e); 

Tworzy zlokalizowany opis tego odniesienia. Podklasy mogą zastąpić tę metodę w celu wygenerowania komunikatu specyficznego dla lokalizacji. W przypadku podklas, które nie zastępują tej metody, domyślna implementacja zwraca ten sam wynik co getMessage().

CASE e to nic innego obiektu wyjątku ...

getLocalizedMessage() u trzeba zastąpić i dać swoją wiadomość tj rozumieniu zlokalizowanego wiadomości.