Ich habe hier Fragen gefunden Sollte eine Abrufmethode "null" zurückgeben oder eine Ausnahme auslösen, wenn es möglich ist 't produzieren den Rückgabewert? und Sollen Funktionen null zurückgeben oder ein leeres Objekt? , aber ich denke, mein Fall ist ganz anders.
Ich schreibe eine Anwendung, die aus einem Webservice und einem Client besteht. Der Webservice ist dafür verantwortlich, auf Daten zuzugreifen und Daten an den Client zurückzugeben. Ich entwerfe meine App so:
// webservice
%Vor%// Kunde:
%Vor%Nun, es gibt eine Regel, die nicht null zurückgibt. Ich denke nicht, dass ich eine Ausnahme einfach erneut auslösen und den Client SoapException abfangen sollte. Was ist dein Kommentar? Gibt es einen besseren Ansatz, um dieses Problem zu lösen?
Danke.
In Ihrem Fall wurde bereits eine Ausnahme in Ihrem Web-Service ausgelöst und behandelt.
Die Rückgabe von null ist eine gute Idee, weil der Client-Code wissen kann, dass etwas in Ihrem Web-Service fehlerhaft ist.
Im Fall des Kunden denke ich, dass es gut ist, wie Sie es haben. Ich glaube nicht, dass es einen Grund gibt, eine weitere Ausnahme auszulösen (obwohl Sie nicht mehr im Web-Service sind).
Ich sage das, weil technisch nichts einen Fehler in Ihrem Client-Code verursacht hat. Sie erhalten nur schlechte Daten vom Webservice. Dies ist nur eine Frage der Handhabung von möglicherweise schlechten Eingaben von einer externen Quelle.
Persönlich, als Faustregel, scheue ich es, Ausnahmen auszulösen, wenn ich schlechte Daten bekomme, da der Client-Code das nicht kontrollieren kann.
Stellen Sie nur sicher, dass Sie die Bedingung data == null so behandeln, dass Ihr Client-Code nicht abstürzt.
Generell versuche ich, meine Webservices so zu gestalten, dass sie ein Flag zurückgeben, das anzeigt, ob ein technischer / funktioneller Fehler aufgetreten ist oder nicht. Außerdem versuche ich, ein komplexes Objekt für das Ergebnis zurückzugeben, nicht nur eine Zeichenkette, so dass ich Dinge wie:
zurückgeben kannresult- & gt; Code="WARTUNG" Ergebnis- & gt; MaintenanceTill="2010-10-29 14:00:00"
also für einen Webservice, der mir eine Liste von dataEntities bringen soll, werde ich etwas zurückgeben wie:
%Vor%Damit ist jeder Fehler, der hinter meinem Webservice auftreten kann, in einem Fehler versteckt. Die einzigen Ausnahmen, die Entwickler beim Aufruf meines Webservice beachten müssen, sind die Ausnahmen oder Fehler, die vor dem Webservice auftreten können.
Alle von mir verwendeten WebServices geben Objekte zurück, keine einfachen Datentypen. Diese Objekte enthalten normalerweise einen bool -Wert namens Success , mit dem Sie sehr schnell testen können, ob Sie den zurückgegebenen Daten vertrauen oder nicht. In jedem Fall denke ich, dass Fehler, die ausgelöst werden, nicht auffindbar (d. H. Unbeabsichtigt) sein sollten und daher ein Problem mit dem Dienst selbst bedeuten.
Ich denke, es gibt einige Faktoren, die bei einer Entscheidung berücksichtigt werden müssen:
Ich tendiere dazu, dass der Klient die einfachste, idiomatische Sache innerhalb der Grenzen der Bibliothek macht. Wenn die Client-Bibliothek sich nicht um das automatische Wiederherstellen von serialisierten Ausnahmen kümmert, würde ich sie wahrscheinlich mit einer Lib umbrechen, die das Folgende ermöglicht:
Kunde:
%Vor%WebService:
%Vor%Ihr erstes Problem ist "eine Regel, die nicht null zurückgibt". Ich würde dringend vorschlagen, das zu überdenken.
Das Zurückgeben einer SoapException ist eine Möglichkeit, aber wie bereits erwähnt, wäre es besser, ein komplexes Objekt mit einer Statusflag {Success, Fail} bei jeder Antwort vom Webservice zurückzugeben.
Wenn Ihr Client und Dienst auf verschiedenen Rechnern oder auf verschiedenen Prozessen läuft, ist es unmöglich , einen Fehler vom Dienst zu erzeugen und ihn auf dem Client abzufangen. Wenn Sie darauf bestehen, Ausnahmen zu verwenden, ist das Beste, auf das Sie hoffen können, ein Proxy auf dem Client, der die Fehlerbedingung (entweder null oder eine andere Konvention) erkennt und eine neue Ausnahme erneut auslöst.
Ich denke, alles läuft auf die Frage hinaus, ob Ihr Kunde irgendwelche Informationen dazu verwenden kann, warum keine Daten zurückgegeben wurden.
Zum Beispiel - wenn keine Daten zurückgegeben wurden, weil der Server (zB sql), der in GetSomeData aufgerufen wurde, nicht aktiv war und der Client tatsächlich etwas mit diesen Informationen machen kann (z. B. eine entsprechende Nachricht anzeigen) - wollen Sie nicht ausblenden diese Information - einen Fehler zu werfen ist informativer.
Ein anderes Beispiel - wenn parameter null ist und das eine Ausnahme verursacht .. (obwohl du wahrscheinlich schon früher im Code darauf geachtet haben solltest. Aber du bekommst die Idee) - sollte eine entsprechende (informative) Exception werfen.
Wenn es dem Client überhaupt nicht interessiert, warum er keine Daten zurückbekommen hat, können Sie null zurückgeben, er wird den Fehlertext sowieso ignorieren und sein Code wird gleich aussehen.
Die allgemeine Praxis bei der Behandlung von Ausnahmen ist, wenn die Sequenz des Flusses unter normalen Umständen erwartet wird, wo die Sequenz aufgrund der Nichtverfügbarkeit von Ressourcen oder der erwarteten Eingabe nicht abgeschlossen werden konnte.
In Ihrem Fall müssen Sie noch entscheiden, wie Ihr clientseitiger Code auf Null oder Ausnahme reagieren soll.
Wie wäre es mit einem Delegierten, der aufgerufen wird, wenn etwas Schlimmes passiert? Der Delegat könnte eine Ausnahme auslösen, wenn dies von außen gewünscht wird, oder die Funktion null zurückgeben lassen (wenn der äußere Code dies überprüft) oder möglicherweise eine andere Aktion ausführen. Abhängig von den Informationen, die an den Delegaten übergeben werden, ist es möglicherweise in der Lage, mit Problemzuständen so umzugehen, dass die Verarbeitung fortgesetzt werden kann (z. B. kann der Delegierte ein "Wiederholungs" -Flag die ersten Male, wenn er aufgerufen wird, setzen, falls das Netzwerk flockig ist Verbindungen werden erwartet). Es kann auch möglich sein, dass ein Delegierter Informationen protokolliert, die zu dem Zeitpunkt nicht existieren würden, an dem eine Ausnahme abgefangen werden könnte.
PS - Es ist wahrscheinlich am besten, eine benutzerdefinierte Klasse an den delegierten Fehler zu übergeben. Dadurch können zukünftige Versionen der Methode zusätzliche Informationen für den Delegaten bereitstellen, ohne dass Implementierungen, die einfachere Informationen erwarten, durchbrochen werden.
CallGetSomeData null zurückgegeben hat, weil a) Daten nicht verfügbar sind oder b) Es gibt eine Datenbankausnahme, da die Tabelle gesperrt ist. Daher ist es immer gut zu wissen, was den Fehler verursacht hat, um das Reporting auf der Client-Seite zu vereinfachen. Sie sollten einen Fehlercode und eine Beschreibung als Teil Ihrer Nachricht haben. Tags und Links exception-handling design exception return-value