Я більш детально спрямую свою відповідь на те, що виникає після винятку: для чого це добре і як має вести себе програмне забезпечення, що повинні робити ваші користувачі з виключенням? Чудовою технікою, з якою я натрапив на початку своєї кар’єри, було завжди повідомляти про проблеми та помилки в 3 частинах: контекст, проблема та рішення. Використання цього dicipline значно змінює обробку помилок і робить програмне забезпечення значно кращим для використання операторами.
Ось кілька прикладів.
Context: Saving connection pooling configuration changes to disk.
Problem: Write permission denied on file '/xxx/yyy'.
Solution: Grant write permission to the file.
У цьому випадку оператор точно знає, що робити і на який файл має впливати. Вони також знають, що зміни в об'єднанні з'єднань не відбулися і повинні повторюватися.
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.
Я пишу на серверних системах, і мої оператори, як правило, підтримують технічну підтримку першого рядка. Я б писав повідомлення по-різному для настільних програм, які мають різну аудиторію, але містять ту саму інформацію.
Якщо скористатися цією технікою, трапиться кілька чудових речей. Розробнику програмного забезпечення часто найкраще знати, як вирішити проблеми у власному коді, тому кодування рішень таким чином, коли ви пишете код, має величезну користь для кінцевих користувачів, які знаходяться у невигідному пошуку рішень, оскільки їм часто не вистачає інформації про що саме робило програмне забезпечення. Кожен, хто коли-небудь читав повідомлення про помилку Oracle, дізнається, що я маю на увазі.
Друга чудова річ, яка приходить вам на думку, - це коли ви намагаєтесь описати рішення, яке виключаєте, і ви пишете "Перевірити Х, а якщо А, то Б ще С". Це дуже чіткий і очевидний знак того, що виняток перевіряється в неправильному місці. Ви програміст маєте здатність порівнювати речі в коді, так що оператори "якщо" повинні бути запущені в коді, навіщо залучати користувача до чогось, що можна автоматизувати? Швидше за все, це з глибшого коду, і хтось здійснив ледачу справу і кинув IOException з будь-якої кількості методів і виявив потенційні помилки з усіх них у блоці коду виклику, який не може адекватно описати, що пішло не так, що конкретноконтекст є і як це виправити. Це спонукає вас писати дрібніші помилки зерна, ловити їх та обробляти їх у потрібному місці у своєму коді, щоб ви могли правильно сформулювати ті кроки, які повинен зробити оператор.
В одній компанії у нас були найвищі оператори, які дуже добре познайомилися з програмним забезпеченням та зберегли власну "програму", яка доповнила наше повідомлення про помилки та запропонувало рішення. Щоб розпізнати це, програмне забезпечення почалося, включаючи вікі-посилання на розгорнуту книгу за винятками, так що було доступне базове пояснення, а також посилання на більш розгорнуті дискусії та спостереження з боку операторів з часом.
Якщо у вас була спроба спробувати цю техніку, стає набагато очевидніше, що слід назвати винятки в коді, коли створюєте свій власний. NonRecoverableConfigurationReadFailedException стає трохи скороченням того, що ви збираєтеся більш повно описати оператору. Мені подобається багатослівний, і я думаю, що наступному розробнику, який торкнеться мого коду, буде простіше інтерпретувати його.