Frage

Meine Gruppe entwickelt eine dienstbasierte Anwendung (.NET WCF) und wir versuchen zu entscheiden, wie Ausnahmen in unseren internen Diensten behandelt werden sollen.Sollten wir Ausnahmen auslösen?Als XML serialisierte Ausnahmen zurückgeben?Einfach einen Fehlercode zurückgeben?

Beachten Sie, dass der Benutzer diese Ausnahmen niemals sehen wird, sondern nur für andere Teile der Anwendung.

War es hilfreich?

Lösung

WCF verwendet SoapFaults als native Methode zum Übertragen von Ausnahmen entweder vom Dienst an den Client oder vom Client an den Dienst.

Sie können einen benutzerdefinierten SOAP-Fehler mithilfe von deklarieren FaultContract Attribut in Ihrer Vertragsschnittstelle:

Zum Beispiel:

[ServiceContract(Namespace="foobar")]
interface IContract
{
    [OperationContract]
    [FaultContract(typeof(CustomFault))]
    void DoSomething();
}


[DataContract(Namespace="Foobar")]
class CustomFault
{
    [DataMember]
    public string error;

    public CustomFault(string err)
    {
        error = err;
    }
}

class myService : IContract
{
    public void DoSomething()
    {
        throw new FaultException<CustomFault>( new CustomFault("Custom Exception!"));
    }
}

Andere Tipps

Warum nicht einfach die Standard-SOAPExceptions auslösen?Das Problem bei Fehlercodes und serialisiertem XML besteht darin, dass beide zusätzliche Logik erfordern, um zu erkennen, dass tatsächlich ein Fehler aufgetreten ist.Ein solcher Ansatz ist nur dann sinnvoll, wenn Sie über eine spezielle Protokollierung oder Logik verfügen, die auf der anderen Seite des Webdienstes erfolgen muss.Ein solches Beispiel wäre die Rückgabe eines Flags mit der Meldung „Es ist in Ordnung, fortzufahren“ mit einem Fehlerausnahmebericht.

Unabhängig davon, wie Sie es auslösen, wird es die Arbeit nicht einfacher machen, da die aufrufende Seite immer noch erkennen muss, dass eine Ausnahme vorliegt, und sich damit befassen muss.

Ich bin etwas verwirrt, ich bin nicht leichtfertig – Sie sagen einerseits, dass Sie als XML serialisierte Ausnahmen zurückgeben möchten und andererseits, dass der Benutzer die Ausnahmen nie sehen wird.Wer wird diese Ausnahmen sehen?

Normalerweise würde ich empfehlen, WCF-Fehlerverträge zu verwenden.

Phil, verschiedene Teile der Anwendung rufen sich gegenseitig über WCF auf.Mit „Als XML serialisierte Ausnahmen zurückgeben“ meinte ich, dass der Rückgabewert der Funktion ein Ausnahmeobjekt sein würde.Der Erfolg würde durch null angezeigt.

Ich glaube nicht, dass das die richtige Option ist.

WCF-Fehlerverträge klingen gut, aber ich weiß nichts darüber.Schaue gerade bei Google nach.

Ich würde es vermeiden, Ausnahmen direkt an den Client zurückzusenden, es sei denn, Sie sind damit einverstanden, dass so viele Details zurückgesendet werden.

Ich würde empfehlen, WCF-Fehler zu verwenden, um Ihre Fehlermeldung und Ihren Code zu übertragen (etwas, das verwendet werden kann, um eine Entscheidung darüber zu treffen, ob der Empfänger es erneut versucht, einen Fehler ausgibt usw.), je nachdem, ob der Sender oder der Empfänger schuld ist.

Dies kann mit FaultCode.CreateReceiverFaultCode und FaultCode.CreateSenderFaultCode erfolgen.

Ich bin gerade dabei, das durchzugehen, bin aber anscheinend auf einen unangenehmen Haken in der durch den WCF-Fehler generierten SOAP 1.1-Antwort gestoßen.Wenn Sie interessiert sind, können Sie meine Frage dazu hier lesen:

.NET WCF-Fehler, die falsche SOAP 1.1-Fehlercodewerte erzeugen

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top