Обработка исключений в веб-приложении Java

Question

Я занимаюсь разработкой веб-приложения Java среднего размера со Struts в качестве инфраструктуры MVC и простого JDBC на уровне доступа к данным. Я искал лучшие практики обработки исключений в таком приложении. Я обнаружил несколько статей, некоторые из которых противоречивы, но только запутывают меня, а не делают вещи ясными и простыми. Некоторые говорят, что лучше повторно использовать существующие исключения, а не определять специфичные для приложения исключения, другие представляют огромную иерархию специфичных для приложения исключений для каждой незначительной проблемы, которая может возникнуть в системе. Некоторые говорят, что лучше не обрабатывать исключения на уровне доступа к данным и делегировать их на уровень обслуживания, другие говорят, что исключения уровня доступа к данным следует перехватывать локально, поскольку делегирование их на уровень обслуживания нарушит абстракцию между двумя уровнями. И так далее.

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

1. Где можно обнаружить исключения SQLE?
2. Где должны регистрироваться исключения?
3. Должны ли регистрироваться непроверенные исключения?
4. Следует ли перехватывать непроверенные исключения на уровне представления и показывать ли они пользователю?
5. Как проверяются исключения, какие из них показывать пользователю и как?
6. Как использовать глобальную страницу обработчика исключений?
7. Каким образом в этом контексте должны использоваться ошибки ActionErrors?

Спасибо

Answer 1

1: Где можно обнаружить исключения SQLE?

В классах DAO на уровне доступа к данным. При необходимости вы можете заключить его в специальное исключение DAO. Это исключение DAO, в свою очередь, требует дальнейшей обработки как проверенное исключение.

2: Где должны регистрироваться исключения?

В тот момент, когда вы собираетесь throw их или пройти через систему обмена сообщениями.

3: должны ли регистрироваться непроверенные исключения?

Они обязательно должны быть зарегистрированы. Именно они должны , а не встречаться в реальном мире, потому что они являются признаком ошибки в логике кода (то есть ошибки разработчика), которая должна быть исправлена ​​как можно скорее. Они должны быть выброшены до самого контейнера и позволить контейнеру обрабатывать их с <error-page> in web.xml. Чтобы зарегистрировать (и в конечном итоге отправить их по почте), используйте Filter, который прослушивает страницу ошибки.

4: Должны ли непроверенные исключения обнаруживаться на уровне представления и показываться ли они пользователю?

Они вообще не должны появляться.

5: Как обрабатываются проверенные исключения, какие из них показывать пользователю и как?

Если они являются результатом ошибочного ввода данных пользователем (например, не числа, плохого адреса электронной почты, нарушения ограничений и т. Д.), Покажите их в той же форме пользователю. В противном случае (например, отключение БД, исключение DAO и т. Д.) Либо перебросьте его до страницы ошибки, либо отобразите сообщение об ошибке, чтобы повторить попытку позже.

6: Как использовать глобальную страницу обработчика исключений?

По крайней мере, в удобной для пользователя форме. Таким образом, в том же макете, с некоторыми вводными «извините» и, если необходимо, с некоторыми подробностями об ошибках и адресом электронной почты, чтобы пользователь мог связаться в этом случае.

7: Каким образом в этом контексте должны использоваться ошибки ActionErrors?

Показывать их пользователю в том же виде.

Answer 2

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

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

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

Я бы ожидал, что объявленные исключения будут на том же уровне абстракции, что и интерфейс / методы, определяющие их. например TradeStore было бы объявлено для выдачи TradeException, а не SQLException (поскольку методы хранения сделки являются реализацией TradeStore - вы можете хранить в реляционной БД, JavaSpace и т. д.).

Answer 3

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