Я направлю свой ответ больше на то, что происходит после исключения: для чего оно хорошо и как должно вести себя программное обеспечение, что должны делать ваши пользователи с исключением? Отличная техника, с которой я столкнулся в начале своей карьеры, состояла в том, чтобы всегда сообщать о проблемах и ошибках в 3 частях: контекст, проблема и решение. Использование этой линии значительно меняет обработку ошибок и делает программное обеспечение намного лучше для операторов.
Вот несколько примеров.
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, поймет, что я имею в виду.
Вторая замечательная вещь, которая приходит на ум, - это когда вы пытаетесь описать решение в своем исключении и пишете «Проверьте X, и если A, то B, еще C». Это очень четкий и очевидный признак того, что ваше исключение проверяется не в том месте. У вас, программиста, есть возможность сравнивать вещи в коде, поэтому «если» операторы должны выполняться в коде, зачем вовлекать пользователя в то, что можно автоматизировать? Скорее всего, это из-за более глубокого в коде, и кто-то сделал ленивую вещь и выбросил IOException из любого числа методов и уловил потенциальные ошибки от всех из них в блоке вызывающего кода, который не может адекватно описать, что пошло не так, что конкретноеконтекст есть и как это исправить. Это побуждает вас писать более мелкие ошибки, отслеживать и обрабатывать их в нужном месте вашего кода, чтобы вы могли правильно сформулировать шаги, которые должен предпринять оператор.
В одной компании у нас были первоклассные операторы, которые действительно хорошо знали программное обеспечение и вели свою собственную «рабочую книгу», которая дополняла наши отчеты об ошибках и предлагаемые решения. Чтобы распознать это, программное обеспечение начало включать вики-ссылки на рабочую книгу в исключениях, чтобы было доступно базовое объяснение, а также ссылки на более продвинутые обсуждения и наблюдения операторов со временем.
Если у вас была возможность попробовать эту технику, становится гораздо более очевидным, как вы должны называть свои исключения в коде при создании своих собственных. NonRecoverableConfigurationReadFailedException становится небольшим сокращением для того, что вы собираетесь более полно описать оператору. Мне нравится быть многословным, и я думаю, что следующему разработчику, который прикоснется к моему коду, будет легче интерпретировать.