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

Question

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

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

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

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

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

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

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

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

Заранее благодарен.

SP

Answer 1

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

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

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

Answer 2

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