Обработка ошибок J2EE - приложение и пользователь

Question

У меня есть вопрос, касающийся обработки ошибок в приложении J2EE. Наше текущее приложение используется многими многими пользователями, и в результате мы получаем много заявок на поддержку. Большинство этих заявок относятся к пользователю, но 5-10% относятся к системным исключениям, необработанным ошибкам и т. Д.

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

Что мне нужно, так это рекомендация по хорошему шаблону проектирования обработки ошибок, поэтому давайте рассмотрим сценарий:

1. Код содержит ошибку
2. Ошибка обработана
3. Пользователю показывается нетехническое сообщение об ошибке с определенным кодом ошибки.
4. Команда нетехнической поддержки может использовать этот код ошибки для просмотра области (страницы, раздела, ...) в приложении, где это произошло, и того, что мог делать пользователь (информация предварительно заполнена командой разработчиков в справочнике службы поддержки клиентов). руководство).
5. Служба технической поддержки может использовать код для обнуления класса / JSP и т. Д. И строку кода, которая вызвала это исключение.
6. Мы используем модуль журналирования, в котором большинство (не все) ошибки стандартного вывода Tomcat регистрируются сессией пользователя ... в код ошибки, который получит пользователь, мы можем включить идентификатор журнала, если он также существует так что техническая команда может посмотреть на это тоже.

По сути, меня интересует сокращение цикла анализа поддержки, объяснения и исследования и предоставление каждому департаменту доступа к информации, которая может помочь им быстрее приступить к работе:

1. Служба поддержки клиентов может дать стандартное объяснение этого кода ошибки или предложить альтернативные действия, которые может выполнить пользователь.
2. Техническая группа может начать устранять неполадки в строке кода или в действиях пользователя, которые вызвали эту строку.

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

Я не уверен, что вышесказанное - даже хорошая идея. Любые предложения будут оценены по хорошей «модели дизайна» для такой необходимости. Или, если это будет хороший маршрут, чтобы посмотреть.

Заранее спасибо.

SP

Answer 1

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

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

Если вы забиты ошибками, для которых, по вашему мнению, вам необходимо составить список кодов / условий ошибок, похоже, что вашему продукту требуется еще 6 месяцев для стабилизации. Вероятно, вы не разрабатываете ОС, и для 99% проектов разработка черной книги кодов ошибок IBMesque не является моделью для подражания.

Answer 2

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