У меня вопрос относительно обработки ошибок в приложении J2EE. Наше текущее приложение используется многими пользователями, и в результате мы получаем много обращений в службу поддержки. Большинство этих заявок связаны с пользователями, но 5-10% - это системные исключения, необработанные ошибки и т. Д.
У нас есть базовые проверки обработки исключений в коде (необходимо работает), но по моему опыту показ общего сообщения пользователю не помогает ускорить процесс устранения неполадок.
Я ищу рекомендацию по хорошему шаблону проектирования обработки ошибок, поэтому давайте рассмотрим сценарий:
- Код имеет ошибку
- Ошибка обработана
- Пользователю отображается сообщение об ошибке нетехнического характера с конкретным кодом ошибки.
- Команда, не имеющая отношения к технической поддержке, может использовать этот код ошибки, чтобы увидеть область (страницу, раздел, ..) в приложении, где это произошло, и что мог делать пользователь (информация предварительно указана командой разработчиков в справочном руководстве по поддержке клиентов).
- Команда технической поддержки может использовать код для обнуления класса / JSP и т. Д. И строки кода, которая вызвала это исключение.
- Мы используем модуль ведения журнала, где большинство (не все) ошибок стандартного вывода Tomcat регистрируются сеансом пользователя ... к коду ошибки, который получит пользователь, мы можем включить идентификатор журнала, если он существует, чтобы техническая команда тоже может взглянуть на это.
В основном меня интересует сокращение цикла поддержки-анализа-объяснения-исследования и предоставления каждому отделу доступа к информации, которая будет у них под рукой, что может помочь им быстрее приступить к работе:
- Служба поддержки клиентов может дать стандартное объяснение этого кода ошибки или предложить альтернативные шаги, которые может выполнить пользователь.
- Техническая группа могла начать устранение неполадок в строке кода или в том, что делал пользователь, вызвавший эту строку.
Существенно, что каждый код ошибки запускает требуемые следующие шаги для каждого отдела и, по сути, сокращает фазу исследования проблемы и переход к фазе решения.
Я не уверен, что это вообще хорошая идея. Мы будем благодарны за любые предложения о хорошем «шаблоне проектирования» для такой необходимости. Или, если бы это был хороший маршрут, чтобы посмотреть.
Заранее спасибо.
SP
