Najlepsze praktyki tworzenia wzorca kodów błędów dla projektu korporacyjnego w C # [zamknięte]

Pracuję nad projektem korporacyjnym, który zostanie wdrożony w wielu małych i średnich przedsiębiorstwach i przedsiębiorstwach.
Wsparcie dla tego projektu byłoby trudne, dlatego chcę stworzyć wzorzec kodowania dla błędów ( jak kody stanu HTTP ). Umożliwi to pracownikom działu pomocy technicznej odnoszenie się do dokumentów i rozwiązywanie problemów tak szybko, jak to możliwe.

Jakie są najlepsze praktyki i zalecenia, aby to zrobić?
Każda pomoc w tym zakresie będzie przydatna.

c# programming-practices error-handling enterprise-development

— Pooya
źródło

Istnieje albo zbyt wiele możliwych odpowiedzi, albo dobre odpowiedzi byłyby za długie dla tego formatu. Dodaj szczegóły, aby zawęzić zestaw odpowiedzi lub wyizolować problem, na który można odpowiedzieć w kilku akapitach. I czego dotychczas próbowałeś.

— Ben McDougall,

Zależy od struktury firmy. W języku C # zawsze dawaliśmy użytkownikowi możliwość wysłania do nas StackTrace lub skopiowania / wklejenia go ze szczegółów komunikatu o błędzie (nie mieliśmy ścisłych wymagań bezpieczeństwa).

— Falcon,

Odpowiedzi:

Istnieje różnica między kodami błędów a zwracanymi wartościami błędów. Kod błędu jest przeznaczony dla użytkownika i działu pomocy technicznej. Zwracana wartość błędu to technika kodowania wskazująca, że kod napotkał błąd.

Można zaimplementować kody błędów za pomocą zwracanych wartości błędów, ale odradzałbym to. Wyjątki stanowią nowoczesny sposób zgłaszania błędów i nie ma powodu, dla którego nie powinny zawierać w sobie kodu błędu.

Tak to zorganizowałbym (zauważ, że punkty 2-6 są niezależne od języka):

Użyj niestandardowego typu wyjątku z dodatkową ErrorCodewłaściwością. Połów w głównej pętli zgłasza to pole w zwykły sposób (plik dziennika / wyskakujące okienko / odpowiedź na błąd). Użyj tego samego typu wyjątku w całym kodzie.
Nie zaczynaj od 1 i nie używaj wiodących zer. Trzymaj wszystkie kody błędów na tej samej długości, aby łatwo było znaleźć zły kod błędu. Począwszy od 1000 zwykle jest wystarczająco dobry. Być może dodaj wiodące „E”, aby były one wyraźnie identyfikowalne dla użytkowników (szczególnie przydatne, gdy dział wsparcia musi pouczyć użytkowników, jak rozpoznać kod błędu).
Zachowaj listę wszystkich kodów błędów, ale nie rób tego w swoim kodzie . Zachowaj krótką listę na stronie wiki dla programistów, którą mogą z łatwością edytować, gdy potrzebują nowego kodu. Dział pomocy powinien mieć osobną listę na własnej wiki.
Nie próbuj wymuszać struktury kodów błędów. Zawsze pojawią się trudne do sklasyfikowania błędy i nie chcesz godzinami dyskutować, czy błąd powinien być w grupie 45xx czy w grupie 54xx. Bądź pragmatyczny .
Przypisz każdemu rzutowi do swojego kodu osobny kod. Nawet jeśli uważasz, że to ta sama przyczyna, dział pomocy technicznej może potrzebować różnych czynności w różnych przypadkach. Łatwiej im mieć „E1234: Zobacz E1235” na swojej wiki, niż skłonić użytkownika do przyznania się do tego, co zrobił źle.
Podziel kody błędów, jeśli poprosi o to dział pomocy technicznej. Prosta if (...) throw new FooException(1234, ".."); else throw new FooException(1235, "..");linia w kodzie może zaoszczędzić pół godziny na pomocy technicznej.

I nigdy nie zapominaj, że celem kodów błędów jest ułatwienie życia działowi pomocy technicznej .

— Sjoerd
źródło

Nigdy nie robiłem tego osobiście, ale często widzisz również „identyfikatory korelacji”, przewodniki specyficzne dla instancji błędu, które są wyświetlane użytkownikowi, a także logowane. W ten sposób łatwiej można znaleźć dokładne wystąpienie błędu w dziennikach, łatwiej niż przy użyciu przybliżonego czasu i kodu błędu.

— xdhmoore

Przypuszczam, że istnieje prawdopodobnie sposób na umieszczenie kodu błędu w identyfikatorze korelacji, aby mógł służyć jako czytelny dla człowieka kod błędu dla działu pomocy technicznej i jako identyfikator wystąpienia błędu dla programistów.

— xdhmoore

Mój wzór jest podobny. Ale zamiast „E” dodałem krótką część aplikacji. Nasza struktura dokumentacji ma np. Czas Doc1234, jaki może mieć aplikacja główna IrS1234. Więc moi współpracownicy z działu pomocy technicznej bardzo szybko pomagają moim użytkownikom.

— Matthias Burger

Najpierw musisz wyodrębnić obszary, w których mogą wystąpić błędy, i są widoczne dla użytkownika. Następnie możesz je udokumentować. To takie proste.

Cóż, proste w teorii ... w praktyce błędy mogą wystąpić w całym tym cholernym miejscu, a ich zgłoszenie może zmienić ładny kod w potwora rejestrowania, zgłaszania wyjątków i obsługi oraz przekazywania wartości zwracanych.

W takim razie zaleciłbym podejście dwuetapowe. Pierwszym z nich jest rejestrowanie, rejestrowanie partii i partii.

Po drugie, należy określić główne komponenty i ich interfejsy oraz zdefiniować, w jakich głównych przypadkach błędów mogą się znaleźć te komponenty. Następnie można zalogować się w bardziej widoczny sposób, gdy jeden z tych błędów (sposób obsługi błędu przez użytkownika zależy od Ciebie - wyjątki lub kody błędów nie mają tutaj znaczenia). Użytkownik zazwyczaj zobaczy błąd i przejdzie do dzienników, aby uzyskać bardziej szczegółowe informacje.

To samo podejście stosuje się w przypadku serwerów internetowych i przykładowego kodu błędu http. Jeśli użytkownik zobaczy 404 i zgłosi wsparcie, przeszukuje dzienniki w celu uzyskania szczegółowych informacji o tym, co się dzieje, która strona została odwiedzona, kiedy, i zbierze wszelkie inne informacje, które może z dowolnego miejsca ma sens , znajdować się w bazie danych, sieci lub aplikacji.

— gbjbaanb
źródło

Wybrałbym niestandardowe wyjątki z opisowymi nazwami i jasnymi wiadomościami i je rzucałem. O wiele łatwiej jest korzystać z istniejącej infrastruktury wyjątków języka niż wbudować obsługę przekazywania kodów błędów i ich interpretacji.

— Stefan Billiet
źródło

Byłbym wdzięczny za osobę, która zanegowała tę odpowiedź od 1 do 0, aby przynajmniej podać powód ...

— Stefan Billiet

nie byłem oddelegowany (nie to, że to ma znaczenie, przełam to), ale myślę, że istnieje wsparcie dla zwracanych wartości również w tym języku.

— gbjbaanb

Ma to dla mnie znaczenie; jeśli się mylę, chciałbym się dowiedzieć, abym mógł się nauczyć :-p Co to znaczy, istniejące wsparcie dla zwracanych wartości? Czy nie musiałbyś pisać hydrauliki, aby odróżnić normalną wartość zwrotną od kodu błędu? Tłumaczenie wyjątku na kod błędu na granicy systemu to jedno, ale żonglowanie nimi w systemie jest czymś, czego się odradza. Wierzę, że Pragmatic Programmer wspomina o takich rzeczach.

— Stefan Billiet

wyjątki nie są dobrym mechanizmem w każdym przypadku, ale jeśli zdecydujesz się użyć błędów, możesz dodać parametr wyjściowy do każdego połączenia lub wszystkie ważne połączenia zwracają kod. Po prostu zdecyduj z góry, aby to zrobić, a będziesz złoty. Pragmatycznie kończy się to kombinacją dwóch - zwracających kody błędów na granicach (więc nie jesteś zamknięty w jednym języku) i wewnętrznych wyjątków.

— gbjbaanb

Nie oddałem głosu (uspokój się, inaczej wszyscy będą musieli to powtórzyć :). Jeśli pracowałeś lub zadzwoniłeś do działu obsługi, o wiele łatwiej jest po prostu podać krótką liczbę niż komunikat błędu. Komunikat o błędzie może ulec zmianie, gdy zostanie przekazany ustnie.

— Codism