Ich implementiere eine Session-Bean, die ApplicationException s auslöst.
Diese Ausnahmen verfügen über verkettete Stack-Traces, die möglicherweise Ausnahmen enthalten, deren Klassen auf dem Client nicht verfügbar sind. Etwas wie:
Hier ist es möglich, dass der Client eine Ausnahme erhält, für die er keine Klasse hat. Dies kann zu folgenden Ergebnissen führen:
%Vor%Ich möchte nicht, dass der Client alle möglichen Ausnahmen kennt, die auf der Serverseite ausgelöst werden können, aber eine Stack-Ablaufverfolgung ist niemals schlecht.
Wie gehen Sie mit diesen Problemen um? Ist es eine passable Lösung, ein Interceptor zu implementieren, das den Stack-Trace entkoppelt, wenn die Ausnahme an den Client zurückgeschickt wird? Aber dann sollte die Interceptor nur Aufrufe über die RemoteInterface verarbeiten, da ich intern an der gesamten Stack-Trace interessiert bin.
Das hängt von Ihrem Client-Typ ab. Wenn ein Client ein anderes Team ist, das eine andere Komponente oder ein anderes Subsystem entwickelt, stimme ich Ihnen zu:
Eine Stack-Trace ist nie schlecht
Aber wenn sie Kunden sind, die keine Ahnung von Ihren internen Anwendungen haben, gibt es keinen Grund für sie, Ihre Ausnahmeklassen zu kennen oder sogar Ihre Stack-Spuren zu sehen. Es wäre schön, ein Protokoll zu haben, das Sie zwingt, alle Ausnahmen zu erfassen und sie in eine Exception-Klasse mit einer error_code -Eigenschaft zu hüllen. Auf diese Weise können Sie für jede catch-Anweisung in Ihrer Anwendung einen spezifischen Fehlercode angeben und Ihren Kunden eine Liste dieser Codes geben.
Wenn Ihre Kunden aus technischer Sicht keinen Zugriff auf Ihre internen Exception -Klassen haben, können sie keinen Zugriff auf Ihre Stack-Ablaufverfolgung haben, ohne dass sie auf ClassNotFoundException verweisen müssen. Wenn Sie wirklich möchten, dass sie den Stack-Trace sehen, könnte eine Lösung ein Aspekt sein, der nur auf der obersten Ebene Ihrer API liegt (die von Clients aufgerufen wird) und alle abfängt Die Exceptions schreiben ihre Stack-Traces in eine String und senden diese als Eigenschaft der letzten Ausnahme, die vom Aufrufer abgefangen wird. Auf diese Weise kann der Aufrufer als formatierte String-Eigenschaft der Ausnahme auf den Stack-Trace zugreifen.
Bearbeiten:
Sie können sogar Ihr Build-Skript konfigurieren, sodass dieser Aspekt niemals Teil Ihrer Release-Versionen ist. So können Sie diese Stack-Trace-Nachrichten nur in Ihrer Debug-Version geben.
Ich habe über eine kleine Umweglösung nachgedacht, aber das sind nur ungeprüfte Spekulationen.
Sie initialisieren Ihre externe Ausnahme mit interner Ausnahme. Aber wenn wir uns Javadoc von Throwable anschauen, können wir sehen, wie Methoden get und setStackTrace (StackTraceElement [] stackTrace)
StackTraceElement wird mit Zeichenfolgen initialisiert. Vielleicht können Sie Stack-Trace von internen Ausnahme erhalten und setzen Sie es in Ihre externe Ausnahme (MyException).
Da sich RMI auf Serialization einstellt, können Sie Serialization -Features verwenden, um Ausnahmen bedingt zu ersetzen.
Nun können Sie jede Ausnahme mit throw new CarryException(originalException); an den Client übergeben. Das CarryException wird immer die Stack-Trace und die Nachricht der ursprünglichen Ausnahme aufzeichnen und die ursprüngliche Ausnahme auf der Clientseite neu erstellen, wenn die Klasse verfügbar ist. Andernfalls sieht der Client CarryException so offensichtlich, dass ein Ausnahmetyp auf der Clientseite bekannt sein muss.
Für den Ausnahmetyp muss der Standardkonstruktor die Nachricht String annehmen, damit die Rekonstruktion funktioniert. (Alle anderen Dinge wären zu kompliziert). Aber die meisten Ausnahmearten haben das.
Es gibt einen weiteren Haken: Ersetzen über Serialization funktioniert nur, wenn Serialization beteiligt ist. Daher dürfen Sie die Methoden der Implementierungsklasse nicht direkt innerhalb derselben JVM aufrufen. Ansonsten sehen Sie das CarryException unbedingt. Sie müssen also einen Stub auch lokal verwenden, z. B.
Aktualisieren
Wenn MyException dem Client bekannt ist und nur LegacyException nicht funktioniert, funktioniert natürlich Folgendes:
Tags und Links java exception-handling java-ee rmi session-bean