Wenn in einem Java-Programm etwas schiefläuft so, wird in den meisten Fällen eine Exception erzeugt und diese nach oben im Stack durchgereicht, bis sie behandelt wird. Manchmal ist es notwendig die Exception bzw. Teile davon in einen String umzuwandeln. Natürlich kann die Exception nun mühsam von Hand auseinander genommen und in einen String konvertiert werden. Sinnvoller ist es die Hilfsmethoden aus der Utility-Bibliothek Guava zu nutzen:
String stacktrace = Throwables.getStackTraceAsString(e);
Bei der Methode getStackTraceAsString wird der Stacktrace der betreffenden Exception in einen String umgewandelt. Neben dieser Methode existieren weitere Methoden rund um das Exception-Handling in der Klasse Throwables. Einfacher wird das Ganze, wenn ein Logger genutzt wird und in diesem die Exception auftauchen soll:
Logger logger = LoggerFactory.getLogger(new Exception().fillInStackTrace().getStackTrace()[0].getClassName());
logger.error("Exception: ", e);
In diesem Fall bieten die meisten Logger die Möglichkeit an, das Throwable direkt als Parameter zu übergeben. Die weitere Verarbeitung der Exception wird anschließend vom Logger erledigt.
Was soll der Blödsinn?
String s = e.toString();
Wenn man den Stacktrace auch haben will, dann pack ihn halt dazu.
Natürlich kann man das Ganze einfach als Blödsinn titulieren. Aber das ist dann etwas zu kurz gedacht. Wenn ich eine Exception werfe, erhalte ich bei folgendem Quellcode:
try { throw new Exception("Fehler 123"); } catch (Exception e) { String s = e.toString(); }in der Variable s ein relativ nichtssagendes:
Für die effektive Fehlersuche benötigt der Entwickler noch einen Stacktrace. Die Exception-Klasse selber bietet mir dafür die Methode printStackTrace, um den Stacktrace auf den Standard-Error-Stream zu bringen und die Methode getStackTrace bei welcher ein Array mit einer Zahl von StackTraceElement(s) zurückgegeben wird.
Dieses kann der Entwickler nun natürlich iterieren und in einen String umwandeln. Wesentlich einfacher und effektiver ist es allerdings das Rad nicht jedes Mal neu zu erfinden und stattdessen vorhandene Utility-Methoden zu nutzen.
Das spart dem Entwickler Zeit und Kosten, die er anderswo im Projekt sicherlich gebrauchen kann. Deshalb ist obige Aussage aus meiner Sicht schlicht zu pauschal gedacht und nicht sonderlich konstruktiv.