Wyjątki lub kody błędów

Budujemy usługę internetową (SOAP, .Net), która będzie rozmawiała z (głównie) rodzimymi klientami (Windows, C ++) i zastanawiamy się, jaki jest najlepszy sposób komunikowania błędów klientowi (np. Coś się stało, że usługa logowania jest niedostępna lub coś takiego, jak użytkownik nie został znaleziony) i nie był w stanie zdecydować między zgłoszeniem wyjątku klientowi a użyciem jakiegoś modelu kodu błędu, aby wykonać powyższe czynności.

Co wolisz w zakresie obsługi po stronie klienta: otrzymanie kodu błędu lub obsługa wyjątku ServerFault, który zawiera przyczynę błędu?
1) Dlaczego myślimy o wyjątku: ponieważ dzięki temu kod po stronie serwera stałby się o wiele bardziej jednolity
2) Dlaczego myślimy o kodach błędów: Ponieważ naszym zdaniem ma to większy sens z punktu widzenia klienta.

Jeśli 2) jest naprawdę prawdą, prawdopodobnie chcielibyśmy wybrać kody błędów niż wyjątki? Czy tak jest w tym przypadku?

Czy zmieniłaby się również odpowiedź, gdybyśmy rozmawiali z klientami zarządzanymi zamiast klientami macierzystymi?

SOAP ma koncepcję błędów , można przekonwertować wyjątek na błąd po stronie serwera, a na serwerze proxy klienta błąd można ponownie przekonwertować na wyjątek. Działa to wyjątkowo dobrze w stosach metra WCF i Java, nie może komentować natywnych klientów C ++.

Jeśli chodzi o najlepszą praktykę SOA, zdefiniuj jeden błąd ogólny i kilka błędów specyficznych tylko wtedy, gdy klient musi inaczej obsłużyć pewien rodzaj błędu. Nigdy nie wysyłaj śledzenia stosu wyjątku do klienta podczas wdrażania produkcyjnego. Jest tak, ponieważ teoretycznie śledzenie serwera nie ma znaczenia dla klienta i ze względów bezpieczeństwa. Zaloguj pełny błąd i stacktrace na serwerze i wyślij unikalne odwołanie do dziennika w błędzie. W WCF używam bloku obsługi wyjątków Microsoft z biblioteki Enterprise Library, aby wygenerować identyfikator GUID, a także przekonwertować wyjątek na błąd SOAP.

Sprawdź wskazówki w Microsoft Patterns and Practices .

Niedawno zrobiłem serwis internetowy z bibliotekami Java 6, który może zgłosić wyjątek z powrotem do osoby dzwoniącej (nie zastanawiałem się, jak to się robi automatycznie).

Możliwość poproszenia klienta o dostarczenie śledzenia stosu w raporcie o błędzie dla programisty była bardzo przydatna (w przeciwieństwie do uzyskiwania przybliżonego znacznika czasu, a następnie musisz sprawdzić go w dziennikach, jeśli zdarzy się, że je zarejestrujesz).

Tak więc, patrząc z punktu widzenia programistów, używaj wyjątków.

Jeśli jest to usługa internetowa, nie można dokładnie spowodować, że serwer zgłosi wyjątek, który zostanie przechwycony przez klienta. W interfejsie serwer zasadniczo musi zwrócić kod błędu, nawet jeśli jest to napis An exception occurred. Type %s, message %s, stack trace %s.

Jeśli chodzi o stronę klienta, możesz poprosić o odczytanie kodu odpowiedzi, aby sprawdzić, czy zawiera błąd i zgłosić wyjątek po stronie klienta. To bardzo dobry sposób na zrobienie tego, przynajmniej w językach z dobrą obsługą wyjątków. Jednak C ++ nie ma dobrego sposobu obsługi wyjątków i dobrym pomysłem jest trzymanie się jak najdalej od wyjątków C ++. Jeśli nie możesz użyć lepszego języka, po prostu trzymaj się kodów błędów.