Руководство по управлению исключениями в веб-приложении Java EE 5

Question

Я был удивлен тем, как трудно найти лучшие практики для этого в Интернете, поскольку это должна быть такая общая проблема.

Приложение основано на Java 1.5 - JSF 1.2 с Faclets, Seam, JPA, Hibernate. Некоторые вызовы веб-службы. Некоторые JMS.

Я получаю общие рекомендации по обработке исключений. Есть примерно три подхода, которые я видел, но я никогда не был уверен, какой из них лучше. Предполагая, что вы не можете восстановиться после ошибки, выполните следующие действия: 1) Запишите ошибку при ее возникновении и повторите бросок?
2) Зарегистрируйтесь, когда это произойдет, и бросьте какое-то общее исключение?
3) Пусть он пузырится, а затем обрабатывает его в универсальном сервлере обработки исключений или аналогичном.

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

Answer 1

Предполагая, что вы не можете исправить ошибку ...

Предполагая, что эта ошибка не является функциональной ошибки, я вхожу ошибку и оберните исключение в (обычая) бесконтрольно исключение, и пусть каркас/контейнер обрабатывают его (так что вариант 2). Я хотел бы сделать это его путь, потому что:

• Мне нравится использование управляемых контейнером транзакций, и я хочу, чтобы контейнер выполнять свою работу (т.е. откатить любой сделки), так бросает исключение во время выполнения является путь.
• Он минимизирует работу по обработке исключений.
• Это упрощает обработку отчетов пользователю с помощью общего подхода.

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

В обоих случаях я использую корневое исключение для каждой иерархии, а именно TechnicalException и FunctionalException.