nicht angemeldet
Rolf BHallo pl,
wie man es sinnvoll in Perl oder JavaScript handhabt weiß ich nicht. Dort ist man frei im geworfenen Wert und kann sich ein Konstrukt bauen, wo Exception-Objekte nur einmal erzeugt und dann immer wieder verwendet werden. Ich würde es aber nicht für eine gute Praxis halten. Das kann aber ein Vorurteil sein, dass ich aus anderen Sprachen habe. Aber du wolltest ja gar nicht über Perl reden 😀.
In PHP, C#, Java ist es üblich, für jeden throw ein neues Exception-Objekt zu erzeugen. Ich müsste es ausprobieren, ob ein throw oldException überhaupt möglich ist oder von der Laufzeitumgebung abgewiesen wird. Habe ich nur leider keine Zeit für dieses Wochenende.
Bei sogenannten inneren Exceptions hast Du auch für eine Fehlersituation mehrere Exception-Objekte gleichzeitig. Beispielsweise habe ich eine C# Funktion, die einen SQL-Zugriff macht. Der fliegt aus der Kurve und ich bekomme vom SQL Treiber eine SqlException. Die hat als innere Exception eine NetworkException, weil der SQL Treiber nämlich den Server nicht erreichen konnte. Anderes Beispiel: die FaultException aus WCF (Windows Communication Foundation), die auftritt wenn ein gerufener Service eine Exception wirft. Die wird von WCF als Service-Fault behandelt, der Client bekommt eine FaultException und darin ist als Testhilfe ein Klon der am Server geworfenen eigentlichen Exception als InnerException enthalten. Sollte natürlich in Produktion nicht vorkommen, das ist ein Knowledge Leak über die Servicestruktur.
Ich hatte schon InnerException-Ketten von 4 Exceptions - das ist dann zwar nicht mehr übersichtlich, aber man kann die Fehlerherkunft schön verfolgen.
Rolf
sumpsi - posui - clusi