Ausnahmen über Remotemethoden

Question

Was sind die besten Verfahren für Ausnahmen gegenüber Remotemethoden?

Ich bin sicher, dass Sie alle Ausnahmen auf der Ebene einer Remote-Methode implementieren müssen, da Sie es auf der Serverseite protokollieren müssen. Aber was solltest du danach machen?

Sollten Sie die Ausnahme in eine RemoteException (Java) umbrechen und sie an den Client übergeben? Dies würde bedeuten, dass der Client alle Ausnahmen importieren müsste, die ausgelöst werden könnten. Wäre es besser, eine neue benutzerdefinierte Ausnahme mit weniger Details zu erstellen? Weil der Kunde nicht alle Details darüber wissen muss, was schief gelaufen ist. Was sollten Sie am Client anmelden? Ich habe sogar von Return-Codes (aus Effizienzgründen?) Gehört, um dem Anrufer mitzuteilen, was passiert ist.

Die wichtige Sache zu beachten, ist, dass der Client informiert werden muss, was schief gelaufen ist. Eine generische Antwort von "Etwas fehlgeschlagen" oder keine Benachrichtigung ist inakzeptabel. Und was ist mit Runtime (unchecked) Ausnahmen?

Answer 1

Hier ist was ich getan habe. Jede Remotemethodenimplementierung fängt alle Ausnahmen auf der Serverseite ab und protokolliert sie. Dann werden sie in eine benutzerdefinierte Ausnahme eingeschlossen, die eine Beschreibung des Problems enthält.Diese Beschreibung muss für den -Client nützlich sein, damit er nicht alle Details der abgefangenen Ausnahme enthält, da der Client sie nicht benötigt. Sie wurden bereits auf der Serverseite angemeldet. Auf dem Client können diese Ausnahmen jetzt wie vom Benutzer gewünscht gehandhabt werden.

Warum ich die Verwendung von Ausnahmen und nicht die Rückgabe von Codes gewählt habe, liegt an einem sehr wichtigen Nachteil der Rückkehrcodes: Sie können sie nicht ohne größere Anstrengung auf höhere Ebenen werfen. Das heißt, Sie müssen unmittelbar nach dem Anruf auf einen Fehler prüfen und ihn dort behandeln. Aber das mag nicht das sein, was ich will.

Answer 2

In früheren Projekten würden wir alle Service Layer (Tier) Exceptions ganz oben auf der Ebene erfassen und die anwendungsspezifischen Fehlercodes/Informationen über DTOs/VOs an die Benutzeroberfläche weiterleiten. Es ist ein einfacher Ansatz, da es ein festgelegtes Muster aller Fehlerbehandlungen gibt, die für jeden Dienst an derselben Stelle auftreten, anstatt über die Service- und UI-Ebenen verstreut zu sein.

Dann die ganze UI zu tun ist, die DTO/VO für ein Flag zu überprüfen (hasError?) Und die Fehlermeldung (en) anzuzeigen, muss es nicht wissen, egal, was die eigentliche Ausnahme war.

Answer 3

Es scheint, als ob Sie unterscheiden können, wenn der Fehler auf einen Systemfehler (z. B. ein Dienst oder eine Maschine ist ausgefallen) oder einen Geschäftslogikfehler (z. B. der Benutzer existiert nicht) zurückzuführen ist.

Ich würde empfehlen, alle Systemausnahmen vom RMI-Aufruf mit einer eigenen benutzerdefinierten Ausnahme zu umhüllen. Sie können die Informationen in der Ausnahme weiterhin pflegen, indem Sie sie als Ursache an Ihre benutzerdefinierte Ausnahme übergeben (dies ist in Java möglich, andere Sprachen sind nicht sicher). Auf diese Weise muss der Client nur wissen, wie er mit der einen Ausnahme bei Systemfehlern umgehen muss. Ob diese benutzerdefinierte Ausnahme aktiviert ist oder ob die Laufzeit zur Debatte steht (hängt wahrscheinlich von Ihren Projektstandards ab). Ich würde diese Art von Versagen definitiv protokollieren.

Fehlschläge bei Geschäftstypen können entweder als separate Ausnahme oder als Standardantworttyp (oder Nullwert) dargestellt werden. Ich würde versuchen, diesen Fehlertyp wiederherzustellen (d. H. Eine alternative Aktion durchzuführen) und nur protokollieren, wenn die Wiederherstellung fehlschlägt.

Answer 4

Ich würde immer die Ausnahme innerhalb meiner Anwendung (auf der Serverseite wie in Ihrer Frage definiert) protokollieren.

Ich würde dann eine Ausnahme werfen, um vom Client gefangen zu werden. Wenn der Aufrufer Korrekturmaßnahmen ergreifen könnte, um die Ausnahme zu verhindern, würde ich sicherstellen, dass die Ausnahme diese Information enthielt (z. B. DateTime argName must not be in the past). Wenn der Fehler durch einen Ausfall eines Systems eines Drittanbieters verursacht wurde, kann ich diese Information an den Anrufer weiterleiten.

Wenn jedoch die Ausnahme im Wesentlichen durch einen Fehler in meinem System verursacht wurde, würde ich meine Ausnahmebehandlung so strukturieren, dass eine nicht-informative Ausnahmebedingungsnachricht (z. B. General failure) verwendet wurde.