Czy projektując wyjątki, powinienem pisać wiadomości zrozumiałe dla użytkownika lub programisty? Kto powinien być czytelnikiem komunikatów o wyjątkach?
Uważam, że komunikaty o wyjątkach w ogóle nie są przydatne i zawsze trudno mi je pisać. Zgodnie z konwencją typ wyjątku powinien już informować nas, dlaczego coś nie działało, a właściwości niestandardowe mogą dodawać jeszcze więcej informacji, takich jak nazwy plików, indeksy, klucze itp., Więc po co powtarzać je w samym komunikacie? Wiadomość wygenerowana automatycznie może również zrobić, a wszystko, co musi zawierać, to nazwa wyjątku z listą dodatkowych właściwości. Byłoby to tak samo przydatne jak odręczny tekst.
Czy nie lepiej byłoby w ogóle nie pisać wiadomości, ale zamiast tego miały specjalne renderery wyjątków, które zajmują się tworzeniem znaczących wiadomości, być może w różnych językach, a nie kodowaniem ich na stałe w kodzie?
Zapytano mnie, czy którekolwiek z tych pytań stanowią odpowiedź na moje pytanie:
- Jak napisać dobry komunikat wyjątku
- Dlaczego wiele komunikatów o wyjątkach nie zawiera przydatnych informacji?
Przeczytałem je oba i nie byłem zadowolony z ich odpowiedzi. Mówią ogólnie o użytkownikach i koncentrują się na treści samej wiadomości, a nie na adresacie, i okazuje się, że może być co najmniej dwóch: użytkownik końcowy i programista. Nigdy nie wiem, z kim powinienem porozmawiać, pisząc komunikaty o wyjątkach.
Myślę nawet, że słynna wiadomość nie ma żadnej realnej wartości, ponieważ po prostu powtarza nazwę typu wyjątku innymi słowami, więc po co w ogóle pisać? Mogę idealnie wygenerować je automatycznie.
Dla mnie wiadomość wyjątkowa nie ma zróżnicowania swoich czytelników. Idealny wyjątek musiałyby zapewnić co najmniej dwie wersje wiadomości: jedną dla użytkownika końcowego i jeden dla dewelopera. Nazywanie tego po prostu wiadomością jest zbyt ogólne. Wiadomość programisty powinna być następnie napisana w języku angielskim, ale wiadomość użytkownika końcowego może wymagać przetłumaczenia na inne języki. Nie da się tego wszystkiego osiągnąć za pomocą tylko jednej wiadomości, więc wyjątek musiałby zawierać pewien identyfikator wiadomości użytkownika końcowego, który, jak już powiedziałem, może być dostępny w różnych językach.
Kiedy czytam wszystkie inne powiązane pytania, mam wrażenie, że komunikat o wyjątku rzeczywiście jest przeznaczony do przeczytania przez użytkownika końcowego, a nie programistę ... pojedyncza wiadomość jest jak zjeść ciasto i zjeść je.
źródło
Odpowiedzi:
Te wiadomości są dla innych programistów
Wiadomości te powinny zostać odczytane przez programistów, aby pomóc im w debugowaniu aplikacji. Może to przybierać dwie formy:
Aktywne debugowanie. W rzeczywistości uruchamiasz debuger podczas pisania kodu i próbujesz dowiedzieć się, co się stanie. W tym kontekście przydatny wyjątek poprowadzi cię, ułatwiając zrozumienie, co się dzieje źle, lub ewentualnie sugerując obejście (chociaż jest to opcjonalne).
Pasywne debugowanie. Kod działa w środowisku produkcyjnym i kończy się niepowodzeniem. Wyjątek jest rejestrowany, ale otrzymujesz tylko komunikat i ślad stosu. W tym kontekście pomocny komunikat wyjątku pomoże ci szybko zlokalizować błąd.
Ponieważ te wiadomości są często rejestrowane, oznacza to również, że nie należy w nich umieszczać poufnych informacji (takich jak klucze prywatne lub hasła, nawet jeśli użyteczne byłoby debugowanie aplikacji).
Na przykład
IOSecurityException
rodzaj wyjątku zgłaszanego podczas zapisywania pliku nie jest zbyt jasny na temat problemu: czy to dlatego, że nie mamy uprawnień dostępu do pliku? A może możemy to przeczytać, ale nie napisać? A może plik nie istnieje i nie mamy uprawnień do tworzenia plików? A może jest zablokowany (mam nadzieję, że w tym przypadku wyjątek będzie inny, ale w praktyce typy mogą być czasami tajemnicze). A może Code Access Security uniemożliwia nam wykonanie jakiejkolwiek operacji we / wy?Zamiast:
jest o wiele bardziej wyraźny. W tym miejscu natychmiast wiemy, że uprawnienia do katalogu są ustawione poprawnie (w przeciwnym razie nie będziemy mogli wiedzieć, że plik istnieje), ale uprawnienia na poziomie pliku są problematyczne.
Oznacza to również, że jeśli nie możesz podać żadnych dodatkowych informacji, które nie są jeszcze w typie wyjątku, możesz pozostawić wiadomość pustą.
DivisionByZeroException
jest dobrym przykładem, w którym wiadomość jest zbędna. Z drugiej strony fakt, że większość języków pozwala na zgłoszenie wyjątku bez określania jego komunikatu, dzieje się z innego powodu: albo dlatego, że domyślny komunikat jest już dostępny, albo dlatego, że zostanie wygenerowany później, jeśli zajdzie taka potrzeba (i wygenerowanie tego wiadomość jest zawarta w typie wyjątku, co ma sens, mówiąc „OOPly” ).Pamiętaj, że ze względów technicznych (często związanych z wydajnością) niektóre wiadomości są o wiele bardziej tajemnicze niż powinny. .NET
NullReferenceException
:jest doskonałym przykładem wiadomości, która nie jest pomocna. Pomocną wiadomością byłoby:
Te wiadomości nie są dla użytkowników końcowych!
Użytkownicy końcowi nie powinni widzieć komunikatów wyjątków. Nigdy. Chociaż niektórzy programiści kończą pokazywanie tych wiadomości użytkownikom, prowadzi to do słabego doświadczenia użytkownika i frustracji. Wiadomości takie jak:
dla użytkownika końcowego absolutnie nic i należy go za wszelką cenę unikać.
Najgorszym scenariuszem jest globalny try / catch, który zgłasza wyjątek użytkownikowi i wychodzi z aplikacji. Aplikacja, która dba o swoich użytkowników:
W pierwszej kolejności obsługuje wyjątki. Większość z nich można obsługiwać bez przeszkadzania użytkownikowi. Sieć nie działa? Dlaczego nie poczekać kilka sekund i spróbować ponownie?
Zapobiega prowadzeniu aplikacji przez użytkownika do wyjątkowego przypadku. Jeśli poprosisz użytkownika o wprowadzenie dwóch liczb i podzielenie pierwszej przez drugą, dlaczego miałbyś pozwolić użytkownikowi wprowadzić zero w drugim przypadku, aby obwinić go kilka sekund później? Co powiesz na wyróżnienie pola tekstowego na czerwono (z pomocną podpowiedzią, że liczba powinna być różna od zera) i wyłączenie przycisku sprawdzania poprawności, dopóki pole nie pozostanie czerwone?
Zaprasza użytkownika do wykonania akcji w formie, która nie jest błędem. Nie masz wystarczających uprawnień, aby uzyskać dostęp do pliku? Dlaczego nie poprosić użytkownika o przyznanie uprawnień administracyjnych lub wybrać inny plik?
Jeśli nic więcej nie działa, pokazuje pomocny, przyjazny błąd, który został napisany specjalnie w celu zmniejszenia frustracji użytkownika, pomaga użytkownikowi zrozumieć, co poszło źle i ostatecznie rozwiązuje problem, a także pomaga mu zapobiec błędowi w przyszłości (jeśli dotyczy).
W swoim pytaniu zasugerowałeś dwa wyjątki: techniczny dla programistów i jeden dla użytkowników końcowych. Chociaż jest to ważna sugestia w niektórych drobnych przypadkach, większość wyjątków powstaje na poziomie, na którym niemożliwe jest przedstawienie znaczącej wiadomości dla użytkowników. Wziąć
DivisionByZeroException
i wyobrazić sobie, że nie mógł zapobiec wyjątek od tego wydarzenia i nie może poradzić sami. Kiedy podział występuje, czy środowisko (ponieważ jest to środowisko, a nie kod biznesowy, który generuje wyjątek) wie, co będzie użytecznym komunikatem dla użytkownika? Absolutnie nie:Zamiast tego można pozwolić, aby wyrzucił wyjątek, a następnie złapał go na wyższym poziomie, na którym znaliśmy kontekst biznesowy i mogliśmy działać odpowiednio, aby faktycznie pomóc użytkownikowi końcowemu, pokazując w ten sposób:
albo może:
Te wiadomości nie są przeznaczone do analizowania
Komunikaty o wyjątkach również nie powinny być analizowane ani wykorzystywane programowo. Jeśli uważasz, że dzwoniący może potrzebować dodatkowych informacji, dołącz je do wyjątku obok wiadomości. Jest to ważne, ponieważ wiadomość może ulec zmianie bez powiadomienia. Typ jest częścią interfejsu, ale komunikat nie jest: nigdy nie należy polegać na nim w przypadku obsługi wyjątków.
Wyobraź sobie komunikat wyjątku:
Chcesz wyodrębnić wartości „500”, „6”, „4” i „377”. Pomyśl trochę o podejściu, którego użyjesz do parsowania, a dopiero potem kontynuuj czytanie.
Masz pomysł Świetny.
Teraz oryginalny programista odkrył literówkę:
powinno być:
Co więcej, programista uważa, że miesiąc / tydzień / godzina nie są szczególnie istotne, więc wprowadza również dodatkową zmianę:
Co dzieje się z parsowaniem?
Zamiast analizować, możesz użyć właściwości wyjątku (które mogą zawierać wszystko, co tylko chcesz, gdy tylko dane zostaną przekształcone do postaci szeregowej):
Jak łatwo jest teraz korzystać z tych danych?
Czasami (np. W .NET) wiadomość może być nawet przetłumaczona na język użytkownika (IMHO, tłumaczenie tych wiadomości jest absolutnie niepoprawne, ponieważ oczekuje się, że każdy programista będzie mógł czytać w języku angielskim). Analiza takich wiadomości jest prawie niemożliwa.
źródło
Odpowiedź na to zależy całkowicie od wyjątku.
Najważniejsze pytanie, które należy zadać, to: „kto może rozwiązać problem?” Jeśli wyjątek jest spowodowany błędem systemu plików podczas otwierania pliku, sensowne może być przekazanie tej wiadomości użytkownikowi końcowemu. Komunikat może zawierać więcej informacji o tym, jak naprawić błąd. Mogę wymyślić jeden ostateczny przypadek w mojej pracy, w którym miałem system wtyczek, który ładował biblioteki DLL. Jeśli użytkownik popełnił literówkę w wierszu polecenia, aby załadować niewłaściwą wtyczkę, podstawowy komunikat o błędzie systemowym faktycznie zawierał przydatne informacje, które pozwolą mu rozwiązać problem.
Jednak przez większość czasu użytkownik nie może usunąć nieprzechwyconego wyjątku. Większość z nich wymaga wprowadzania zmian w kodzie. W takich przypadkach konsument wiadomości jest wyraźnie programistą.
Przypadek przechwyconych wyjątków jest bardziej skomplikowany, ponieważ masz możliwość prawidłowego przetworzenia wyjątku i rzucenia bardziej przyjaznego. Jeden język skryptowy, który napisałem, wyrzucił wyjątki, których przesłanie było wyraźnie przeznaczone dla programisty. Jednak gdy stos się rozwinął, dodałem czytelne dla użytkownika ślady stosu z poziomu języka skryptowego. Moi użytkownicy bardzo rzadko potrafili odczytać komunikat, ale mogli sprawdzić ślad stosu w swoim skrypcie i dowiedzieć się, co się dzieje w 95% przypadków. Przez pozostałe 5%, kiedy do mnie zadzwonili, mieliśmy nie tylko ślad stosu, ale także wiadomość przygotowaną przez programistę, która pomogła mi ustalić, co było nie tak.
Podsumowując, wiadomość o wyjątku traktuję jako nieznaną treść. Ktoś dalej, kto wiedział więcej o implementacjach, podał mojemu oprogramowaniu wyjątek. Czasami mam przeczucie, że nieznana treść będzie przydatna dla użytkownika końcowego, a czasem nie.
źródło