Wyjątki lub kody błędów

12

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?

Amit Wadhwa
źródło
Wystarczy dodać trochę wyjaśnienia: a) szukam tutaj najlepszych praktyk i doświadczenia po stronie klienta (ponieważ klient jest o wiele bardziej skomplikowany i wolelibyśmy poradzić sobie po stronie serwera, gdybyśmy mogli uprościć kod klienta) b) Klient zawiera dużo starszego kodu i możemy, ale nie musimy, używać wyjątków C ++.
Amit Wadhwa,
To może pomóc- www.codeproject.com/KB/cpp/cppexceptionsproetcontra.aspx
Gulshan

Odpowiedzi:

8

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 .

softveda
źródło
Dzięki, to brzmi dobrze. Czy możesz podać mi bardziej szczegółowy link tam na stronie tam.
Amit Wadhwa,
A co z błędami na poziomie biznesowym, takimi jak UserNotFound itp., Czy powinny być one traktowane jako wyjątki
Amit Wadhwa,
Minęły projekty, w których nigdy nie używaliśmy wyjątków w kodzie ani błędów w SOAP, aby komunikować się z uzasadnionymi / oczekiwanymi trybami awarii. Użyliśmy kodów błędów i pozostawiliśmy je klientowi, aby zdecydował, co z nimi zrobić. Nie znaleziono użytkownika nie jest tak naprawdę błędem / wyjątkiem, prawdopodobnie powinien to być kod stanu.
MrLane
4

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.


źródło
1
Zgadzam się, że może to być przydatne w karmie dla psów i wersji beta, ale czy naprawdę chcesz wyrzucić ślady stosu w dziennikach zdarzeń lub plikach dziennika w czasie rzeczywistym (i oczywiście ujawniając więcej szczegółów na temat usługi, niż potrzebujesz / chcesz w trakcie przetwarzania) )
Amit Wadhwa,
2
@Amit, zaufaj mi w tym przypadku: jeśli trafisz na sytuację, w której podasz ślad stosu podczas produkcji, CHCESZ ślad stosu!
1
Jaka jest korzyść ze śledzenia stosu po stronie klienta, zdecydowanie przekażemy wszystkie wyjątki po stronie serwera przed przekazaniem go do klienta.
Amit Wadhwa,
A co z błędami na poziomie biznesowym, takimi jak UserNotFound itp., Czy powinny być one traktowane jako wyjątki
Amit Wadhwa,
-2

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.

Mason Wheeler
źródło
Wydaje mi się, że nieprzechwycony wyjątek przejdzie jako błąd serwera do klienta
Amit Wadhwa,
3
Nie ma nic złego w wyjątkach C ++ lub C ++. Istnieje wiele powodów, aby używać języka innego niż C ++ w niektórych projektach, ale obsługa wyjątków nie jest jednym z nich.
KeithB,
Nie tylko dlatego, że jest to sprzeczne z najlepszymi praktykami bezpieczeństwa: co dokładnie powinien zrobić klient ze śledzeniem stosu serwera? Wydrukować i wysłać do ciebie? Wysłać jako e-mail? Użyj do smarowania papieru?
JensG,
@JensG: Jeśli jest to usługa internetowa, a nie witryna internetowa , klient powinien być wystarczająco profesjonalny, aby przesłać go e-mailem jako zgłoszenie błędu.
Mason Wheeler,