Как следует планировать исключения на архитектурном уровне?

Question

Есть ли хорошие ресурсы для планирования, как исключения будут использоваться с точки зрения архитектуры? (Или предоставьте свои предложения прямо здесь.) В проектах, над которыми я работал, я обнаружил, что несколько распространенных исключений используются снова и снова и имеют тенденцию терять свое значение. От: http://jamesjava.blogspot.com/2007/10/exception-plan.html

Answer 1

Я наполовину согласен с комментарием Apocalisp. Экземпляры исключения должны быть зарезервированы для случаев, когда произошла ошибка данных или обработки, но могут быть восстановлены с помощью вмешательства пользователя или системы. Экземпляры RuntimeException должны быть зарезервированы для тех случаев, когда никакое вмешательство в пределах вашего приложения не может решить проблему. Таким образом, эти два типа известны как исключения с проверкой и без проверки.

Примером Непроверенных исключений может быть, если физический ресурс (например, база данных или шина сообщений) недоступен. RuntimeException хороша в этом случае, потому что вы не планируете, чтобы ресурс был недоступен, поэтому ваша бизнес-логика не должна постоянно проверять DatabaseUnavailableException или что-то подобное. Вы можете обрабатывать исключения RuntimeException по-другому (например, AOP, отправляя электронное письмо), чтобы сообщить о сбое и позволить персоналу или службе поддержки устранить физическую проблему.

Примерами проверенных исключений могут быть плохой ввод данных, или неполный доступ к данным, или что-то, что фактически не соответствует бизнес-логике, но может быть проверено и восстановлено. Примером этого может быть то, что пользователь, которого вы искали, недоступен. Это отдельное условие в вашей бизнес-логике, которое может быть проверено и обработано (например, частью View вашего приложения, которая затем сообщает пользователю сообщение об исключении как сообщение об ошибке).

Многие фреймворки используют эту модель, и она работает лучше, чем я видел в других случаях.

При этом многие заменяют проверенные исключения возвращаемыми нулями, -1, пустой строкой или Number.MIN_VALUE. Хотя это нормально, если вы обычно не ожидаете этих значений от источника данных или метода, его, вероятно, следует представлять как исключение.

Answer 2

Я обычно нахожу, что одержимость проверенными исключениями излишня. Исключения должны быть зарезервированы для непредвиденных ошибок, из-за которых программа не может разумно восстановиться. Для них я склонен согласиться с тем, что вы заметили, что специальные типы ошибок имеют тенденцию терять свое значение.

Как правило, выдается исключение, когда выполняются все следующие условия:

• Состояние не может быть восстановлено отсюда.
• Нельзя ожидать, что вызывающий абонент восстановится после этого состояния.
• Кто-то захочет отладить ситуацию, поэтому он может захотеть увидеть трассировку стека.

Вы обнаружите, что если все они верны, тип исключения не важен, и вы также можете бросить java.lang.Error. Если какое-либо из них имеет значение false, исключение, вероятно, является избыточным (вам действительно нужен тип, сообщение и трассировка стека?)

Вместо этого рассмотрите возможность увеличения возвращаемого типа методов, чтобы указать ожидаемые виды сбоев. Например, используйте тип Option для методов, в которых в некоторых случаях может иметь смысл не возвращать значения. Используйте тип Either для методов, где вам может потребоваться вернуть значение, тип которого зависит от неудачи или успеха. Там, где раньше у вас могли быть специализированные подтипы Exception, вместо этого вы можете просто использовать Either , где Fail - просто перечисление ожидаемых отказов.

Answer 3

Я стараюсь убедиться, что количество мест, использующих try / finally, значительно превосходит количество мест, использующих try / catch. catch обычно будет зарезервирован для перехвата исключений на верхнем уровне, где они могут быть разумно обработаны, или для обработки исключений из API платформы.

В этом случае, до тех пор, пока вы даете исключительные сообщения и цепочки исключений, где это необходимо, неспособность идентифицировать исключение по его классу не является большой потерей. Я часто выбрасываю RuntimeException, а не пытаюсь разработать класс исключений для каждого возможного случая ошибки, но ваше мнение об этом будет зависеть от того, где вы будете участвовать в дебатах с проверкой и без проверки.

Answer 4

«Эффективная Java», 2-й. редактор У Блоха есть хороший совет в главе 9.

«Хардкорная Java», Симмонс , дает несколько полезных советов в главе 5.

Я также позорно упомяну, что я написал небольшой инструмент для управления исходным кодом исключений Java. Код исключения часто очень избыточен, все, что вас обычно волнует, это тип. Мой инструмент принимает файл конфигурации с именами типов исключений, а затем генерирует код для этих исключений.