Обработка исключений в веб-приложении Java
Я разрабатываю веб-приложение Java среднего размера со стойками как MVC framework и простой JDBC на уровне доступа к данным. Я искал рекомендации по обработке исключений в таком приложении. Я нашел несколько статей, некоторые из них противоречивы, только делают меня более запутанным, а не делают вещи ясными и простыми. Некоторые говорят, что лучше повторно использовать существующие исключения вместо определения исключений конкретного приложения, другие представляют огромную иерархию исключения применения специфические для каждой небольшой тревоги которая может произойти в системе. Некоторые говорят, что лучше не обрабатывать исключения на уровне доступа к данным и делегировать их на уровень сервиса, другие говорят, что исключения уровня доступа к данным должны быть пойманы локально, поскольку делегирование их на уровень сервиса нарушит абстракцию между двумя слоями. И так далее.
Я был бы очень признателен, если бы вы сообщили мне о ссылках / именах на статьи / книги, которые представляют твердые решения, которые имеют сработало для вас по такому сценарию. Решение должно прояснить, по крайней мере, следующие моменты с обоснованиями:
- где SQLExceptions быть пойманы?
- где должны регистрироваться исключения?
- должны ли регистрироваться непроверенные исключения?
- должны ли непроверенные исключения быть пойманы на уровне презентации и должны ли они быть показаны пользователю?
- как проверенные исключения обрабатываются, какие из них должны быть показаны пользователю и как?
- как следует использовать глобальную страницу обработчика исключений?
- как следует использовать struts ActionErrors в этом контексте?
спасибо
3 ответов
1: где SQLExceptions быть пойманным?
в классах DAO на уровне доступа к данным. При необходимости можно обернуть его пользовательским исключением DAO. Это исключение DAO, в свою очередь, должно обрабатываться далее как проверенное исключение.
2: где должны регистрироваться исключения?
в тот момент, когда вы собираетесь throw их или пройти через структуру обмена сообщениями.
3: следует снять флажок исключения регистрируются?
они, безусловно, должны быть зарегистрированы. Они должны именно не происходят в реальном мире, потому что это признак ошибки в логике кода (т. е. ошибка разработчика), которая должна быть исправлена как можно скорее. Они должны быть брошены до самого контейнера и позволить контейнеру обрабатывать их с помощью <error-page> на web.xml. Чтобы зарегистрировать (и в конечном итоге отправить) их, используйте Filter, который слушает на страницу ошибки.
4: должны непроверенные исключения будут пойманы на уровне презентации, и должны ли они быть показаны пользователю?
они вообще не должны происходить.
5: как обрабатываются проверенные исключения, какие из них должны быть показаны пользователю и как?
если они являются результатом неправильного ввода пользователем (например, не номер, плохая электронная почта, нарушение ограничений и т. д.), покажите их в той же форме пользователю. В противном случае (например, DB down, DAO exception и т. д.) либо бросьте его вплоть до страницы ошибки или отображения ошибки с сообщением, чтобы повторить попытку позже.
6: Как следует использовать глобальную страницу обработчика исключений?
по крайней мере в удобной для пользователя форме. Таким образом, в том же макете, с некоторыми вводными "извините" и при необходимости с некоторыми деталями ошибки и адресом электронной почты, чтобы пользователь мог связаться для этого случая.
7: как должны распорки ActionErrors быть использованы в этом контекст?
показать их в той же форме для пользователя.
если вы не можете восстановить из исключения, то вы должны позволить ему вытекать из вашего кода (часто делая его непроверенным или обертывая его в непроверенное исключение). Если они остаются проверенными, вы должны обслуживать их на каждом уровне вашего кода и, следовательно, на каждом уровне абстракции. SQLExceptions обычно попадают в эту категорию (вам придется обернуть их, так как они проверены).
для этих исключений я обычно регистрируюсь на самом высоком уровне, но представляю страницу пользователи просто подробно, что что-то пошло не так. Обычно мои пользователи не интересуются трассировками стека. Но я обычно предлагаю им страницу, чтобы они могли описать, что они делали в то время, и зарегистрированное исключение связывается с этой подачей через уникальный идентификатор (записанный в форме и в файле журнала с исключением). Это позволяет мне привязать действия пользователей к полученному исключению.
выше предполагает, что вы не можете оправиться от SQLExceptions, а если базы данных, то вы не можете сделать что-то значимое. Конечно, есть исключения. Вы можете обнаружить, что вы разговариваете с несколькими системами, и одно из них не означает, что вы не можете продолжать каким-то образом (например, домашняя страница Amazon, как сообщается, полагается на 100 служб и должна работать независимо от некоторых из них).
Я бы ожидал объявил исключения должны быть на том же уровне абстракции, что и интерфейс/методы их определения. например TradeStore будет объявлено, чтобы бросить TradeException, а не SQLException (так как методы хранения торговли являются реализацией TradeStore - вы можете хранить в реляционной БД, JavaSpace и т. д.).
в качестве предупреждения при отображении пользователям сообщений об ошибках нижнего уровня убедитесь, что они очищены от системной информации. Это область, где происходят многие подвиги безопасности. Войти их с полной информацией, но только отображать более общее сообщение об ошибке для пользователя.