Strategie obsługi wyjątków WCF

Oto, co zrobiłem. Mamy kilka niestandardowych WYJĄTKÓW w naszej aplikacji, takich jak BusinessRuleException i ProcessException, WCF obsługuje zarówno FaultException, jak i FaultException<T>.

Ogólna praktyka wydaje się być taka, że zawsze rzucasz FaultException klientowi w przypadku ogólnego błędu lub błędu, który nie chcesz wyświetlać dokładnie tego, co się stało. W innych przypadkach można przekazać FaultException<T> Gdzie T jest klasą z informacją o konkretnym wyjątku.

I created this pojęcie naruszenia w aplikacji, co zasadniczo oznaczało, że każdy niestandardowy wyjątek miał właściwość zawierającą odpowiednią instancję naruszenia. Ta instancja została następnie przekazana klientowi, umożliwiając klientowi rozpoznanie, kiedy wystąpił możliwy do odzyskania błąd.

To rozwiązało część problemu, ale nadal chciałem ogólnego złapać wszystko, co pozwoliłoby mi centralizować logowanie. Znalazłem to poprzez użycie interfejsu Ierorhandle i dodanie własnego niestandardowego programu obsługi błędów do WCF. Oto kod:

public class ServiceHostGeneralErrorHandler : IErrorHandler
{
    public void ProvideFault(Exception ex, MessageVersion version, ref Message fault)
    {
        if (ex is FaultException)
            return;

        // a general message to the client
        var faultException = new FaultException("A General Error Occured");
        MessageFault messageFault = faultException.CreateMessageFault();
        fault = Message.CreateMessage(version, messageFault, null);
    }

    public bool HandleError(Exception ex)
    {
        // log the exception

        // mark as handled
        return true;
    }
}

Za pomocą tej metody mogę przekonwertować wyjątek z tego, co to jest, na coś, co może być łatwo wyświetlane na kliencie, jednocześnie rejestrując prawdziwy wyjątek, aby personel IT mógł go zobaczyć. Jak na razie to podejście działa całkiem dobrze i ma taką samą strukturę jak inne moduły w aplikacji.

Używamy blokowania aplikacji obsługujących wyjątki i chronimy większość błędów przed klientami, aby uniknąć ujawniania poufnych informacji, Ten artykuł może być dobrym punktem wyjścia dla ciebie, podobnie jak w przypadku "najlepszych praktyk" - powinieneś używać tego, co pasuje do Twojej domeny.