我使用sl4j/logback作爲日誌記錄框架。我不確定正確的方式來記錄錯誤。也就是說，假定e是一個例外，我想記錄，我一直猶豫之間：日誌記錄良好做法
logger.error("Something bad happened: {}\nError: {}", someInfo, e.getMessage());
我明白這是不好的做法，因爲堆棧跟蹤丟失 - 並不大明白髮生了什麼。
logger.error("Something bad happened: {}\nError: {}", someInfo, e.getMessage(), e);
同時使用e.getMessage()和e似乎是多餘的，雖然我不知道這是否是可能的，e.getMessage()可能包含，如果我使用，不會被視爲額外的信息：
logger.error("Something bad happened: {}", someInfo, e);
這是我通常使用的語法 - 但我想確保我不會錯過任何東西。
我通常使用兩個號碼，但我從來沒有打破記錄的一條線到2號線（\ n）的，雖然打印堆棧跟蹤時，它不會多大關係（在所有其他情況下，它創建當你的日誌變得真的很大時，太多的視覺熵）。
爲什麼我要用2號？
我想立即在第一行看到該消息，因爲這是告訴我發生了什麼事的第一件事情。有些可能是預期的，我可以安全地跳過它們，有些可能不會。
如果我需要仔細檢查發生了什麼，我會更好地瞭解一下堆棧跟蹤。
我認爲3號也很好，因爲你會得到你需要的信息。 切勿使用選項1.
順便說一句，只是一個獨特的見解，他說，壞事發生在一個錯誤行是有點多餘;）
如果你看的Throwable的源代碼（HTTP ：//www.docjar.com/html/api/java/lang/Throwable.java.html），你會發現Throwable當被要求打印它的堆棧跟蹤時，會自動打印它的信息。
我覺得不太可能有人會更改此行爲，所以你的論點是正確的和3選項是好的
你一定要堆棧跟蹤。 在您做過類似「錯誤：無法找到ID爲{0}的客戶」的情況下，消息很方便，這可能不在堆棧跟蹤中。微不足道的例子，但你明白我的意思。
另一個消息是，如果你做日誌爲說csv，所以你可以分析它。您可以標準化消息，並使過濾更容易。
最後但並非最不重要的錯誤日誌中的多餘信息，方式方式不是一個問題，那麼你不需要在它的信息。嚴格冗長的一面是我的指導原則。
哦，這是爲了控制訪問日誌文件，從來沒有說過把堆棧跟蹤作爲一個響應在asp例如。黑客溼了夢想。