Архитектура обработки исключений для проектов Java EE

Question

Я пытаюсь собрать информацию о том, как другие программисты Java EE выполняют обработку своих исключений. Вы централизуете обработку ошибок (например, фильтр сервлетов)?

Создаете ли вы разные типы исключений для разных прикладных уровней (постоянство, служба и т. Д.)?

Вы просто проглатываете исключения и вообще не бросаете их в цепочку?

Какие еще парадигмы существуют в архитектуре обработки исключений? Что вы используете и почему?

Answer 1

Уровень персистентности, если он реализован с использованием JPA или Hibernate, уже имеет свои собственные исключения, которые являются исключениями времени выполнения.

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

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

Все другие исключения времени выполнения, исходящие от уровня представления, бизнес-уровня или уровня постоянства, обрабатываются одним или несколькими глобальными обработчиками исключений (большинство структур пользовательского интерфейса поддерживаютих), которые регистрируют исключение и выдают более или менее общее сообщение об ошибке (пример: «Произошла непредвиденная ошибка», «Другой пользователь изменил или удалил объект, который вы пытались изменить»).

Answer 2

Исключениями являются чистое золото , поскольку вы пытаетесь выяснить, что пошло не так.Относитесь к ним соответственно!

Глотание исключений допустимо только в очень немногих случаях, когда это действительно подходящее действие.

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

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

В известных случаях можно предпринять соответствующее действие.

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

Answer 3

Я категорически против практики глотания исключений. Это лучший способ тратить столько времени на изучение причин возникновения проблемы. У меня было так много моментов, когда я в конце концов нашел скрытое исключение в пустом предложении catch. Я согласен с Турбьёрном в том, что большую часть времени у вас есть одна лучшая попытка поймать. Внутри него я использую много методов, которые могут генерировать исключения, и чтобы избежать обработки ошибок, я предпочитаю ловить исключения только в верхнем улове.
Насчет централизации , я считаю, что ваши файлы журналов должны быть достаточно центральными.