Swoją odpowiedź skieruję bardziej na to, co nastąpi po wyjątku: po co to jest dobre i jak powinno się zachowywać oprogramowanie, co użytkownicy powinni zrobić z wyjątkiem? Świetną techniką, na którą natknąłem się na początku mojej kariery, było zawsze zgłaszanie problemów i błędów w 3 częściach: kontekst, problem i rozwiązanie. Korzystanie z tej przewagi ogromnie zmienia obsługę błędów i sprawia, że oprogramowanie jest znacznie lepsze dla operatorów.
Oto kilka przykładów.
Context: Saving connection pooling configuration changes to disk.
Problem: Write permission denied on file '/xxx/yyy'.
Solution: Grant write permission to the file.
W takim przypadku operator dokładnie wie, co zrobić i na jaki plik należy to zmienić. Wiedzą również, że zmiany w puli połączeń nie zostały przyjęte i powinny zostać powtórzone.
Context: Sending email to 'abc@xyz.com' regarding 'Blah'.
Problem: SMTP connection refused by server 'mail.xyz.com'.
Solution: Contact the mail server administrator to report a service problem. The email will be sent later. You may want to tell 'abc@xyz.com' about this problem.
Piszę systemy po stronie serwera, a moi operatorzy są zorientowani na technologię pierwszej linii. Napisałbym inaczej w przypadku programów komputerowych, które mają różnych odbiorców, ale zawierają te same informacje.
Gdy używa się tej techniki, dzieje się kilka cudownych rzeczy. Deweloper oprogramowania jest często najlepiej przygotowany do rozwiązywania problemów we własnym kodzie, więc kodowanie rozwiązań w ten sposób podczas pisania kodu jest ogromną korzyścią dla użytkowników końcowych, którzy mają trudności ze znalezieniem rozwiązań, ponieważ często brakuje im informacji o co dokładnie robiło oprogramowanie. Każdy, kto kiedykolwiek przeczytał komunikat o błędzie Oracle, będzie wiedział, co mam na myśli.
Drugą cudowną rzeczą, która przychodzi na myśl, jest próba opisania rozwiązania w twoim wyjątku i piszesz „Sprawdź X, a jeśli A to B jeszcze C”. Jest to bardzo wyraźny i oczywisty znak, że Twój wyjątek jest sprawdzany w niewłaściwym miejscu. Wy, programiści, macie możliwość porównywania rzeczy w kodzie, więc „jeśli” instrukcje powinny być uruchamiane w kodzie, po co angażować użytkownika w coś, co można zautomatyzować? Możliwe, że jest to z głębszego kodu, a ktoś zrobił leniwą rzecz i wyrzucił wyjątek IOException z dowolnej liczby metod i wyłapał potencjalne błędy z każdego z nich w bloku wywołującego kodu, który nie może odpowiednio opisać, co poszło źle, co konkretniekontekst jest i jak to naprawić. To zachęca Cię do pisania drobniejszych błędów ziarna, wychwytywania i obsługiwania ich we właściwym miejscu w kodzie, abyś mógł poprawnie wyartykułować kroki, które powinien podjąć operator.
W jednej firmie mieliśmy najlepszych operatorów, którzy naprawdę dobrze poznali oprogramowanie i prowadzili własną „księgę”, która poprawiła nasze zgłaszanie błędów i sugerowało rozwiązania. Aby to rozpoznać, oprogramowanie zaczęło w wyjątkowych przypadkach włączać linki wiki do księgi głównej, tak aby dostępne było podstawowe wyjaśnienie, a także łącza do bardziej zaawansowanych dyskusji i spostrzeżeń operatorów.
Jeśli masz doświadczenie w wypróbowaniu tej techniki, staje się o wiele bardziej oczywiste, jak powinieneś nazwać swoje wyjątki w kodzie podczas tworzenia własnego. NonRecoverableConfigurationReadFailedException staje się trochę skrótem tego, co zamierzasz pełniej opisać operatorowi. Lubię być gadatliwy i myślę, że będzie to łatwiejsze dla następnego programisty, który dotknie mojego kodu do interpretacji.