Нужно пересмотреть комментарии для моего механизма регистрации ошибок - PullRequest
0 голосов
/ 31 марта 2009

На каждом перерыве в Production / QA / Dev получение корня исключения является очень важным и требующим времени процессом.

Поскольку веб-приложения работают в многопользовательской среде и не имеют состояния \ асинхронного (HTTP), поиск файлов журналов событий / корней и их основной причины - действительно сложная задача; Также это зависит от того, насколько обучен Конечный пользователь, чтобы подробно объяснить проблему.

Я придумал творческий способ записать исключения. Что облегчает работу для конечного пользователя и команды разработчиков?

Мы будем следовать подписи, чтобы записывать исключения в файл XML, и которые можно обрабатывать удаленно для просмотра или создания отчетов об исключениях

Подпись метода Static в классе регистрации ошибок выглядит следующим образом

WriteLog (уникальный номер, имя модуля, приоритет, уровень, пользовательское сообщение строки, исключение с трассировкой стека);

Я знаю, что есть много многократно используемых библиотек обработки исключений, но я посмотрел на уникальный номер, чтобы отследить проблему, которая должна отображаться для конечного пользователя

Ответ пользователю:

Если ожидается, что Исключение будет обработано и использовано, разработчик покажет действительное удобное для пользователя сообщение конечному пользователю. В случае непредвиденных или исключительных ситуаций на прикладном уровне (Global .asax) ответ будет очищен, и пользовательское сообщение в HTML будет записано обратно пользователю с уникальным идентификатором, как показано ниже

«Произошла непредвиденная ошибка, исключение было записано для дальнейших действий; Пожалуйста, используйте # уникальный номер, сгенерированный , чтобы сообщить команде поддержки «

Сведения о параметре:

Уникальный номер: Это уникальный номер, генерируемый для каждого исключения, свойство только для чтения (get) в классе ErrorLogging, которое будет уникальным для каждого исключения, это будет конкатенация Час + Минуты + Секунды + Миллисекунды ; изначально я думал использовать GUID, но потом конечному пользователю было бы сложно запомнить GUID, чтобы сообщить о проблеме.

Открытая строка strExceptionID {

      Get { 

      return  DateTime.Now.ToString(“HHmmssfff”);

          }    

     }

Имя модуля: это будет статическая переменная Enum с именем модуля Пример: enum ModuleName {

    Module1, 

    Module2, 

    Module3  };

Приоритет: это будет переменная Static Enum с Приоритетом, разработчик должен определить приоритет, например, если это ошибка проверки даты или целочисленного формата с использованием «Низкий» или если она неожиданна в вызове бизнес-уровня, тогда используйте «2» ,

Я думаю, что Priority High следует использовать только в DAL или в Business Logic Layer или как, например, в случае сбоя интерфейса с SAP или Ariba. Пример: enum Priority {

        High =1, 
      Medium =2, 
      Low =3, };

Слой:

Это будет переменная Static Enum со слоем Пример: enum Layer {

      Presentation, 
      Business, 
      DataAccess 
            };

Строка Пользовательское сообщение:

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

Исключение с трассировкой стека: это будет объект исключения, который будет дополнительно обработан внутри метода.

Обработка, выполненная внутри метода журнала ошибок:

Метод дополнительно получает вошедший в систему идентификатор пользователя и временную метку и записывает их в файл XML.

Плюсы:

-> XML Logging позволит нам обработать его любым способом -> Исключения можно просматривать удаленно в браузере. -> Легко отследить и найти любое исключение. -> Мы можем искать, сортировать исключения на основе модуля, приоритета, отметки времени, идентификатора пользователя и т. Д. -> Мы можем генерировать отчеты @ Уровень модуля, Уровень, Приоритет, Время ...

Минусы: Зависимость от XML-файла: если он потеряет все исключения, все равно возникнет ошибка, мы можем преодолеть это двумя способами; своевременная запись xml в базу данных или запись в журнале просмотра событий, поскольку у нас всегда будет резервная копия.

На основании тeview комментарии Я опубликую XML-схему и страницу ASPX для просмотра и поиска ошибок.

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

Ответы [ 6 ]

3 голосов
/ 31 марта 2009

У меня есть небольшая ошибка в том, что люди переписывают API-интерфейсы трассировки, не понимая, что платформа даст им «из коробки». Итак, давайте посмотрим на ваш вызов API:

WriteLog (уникальный номер, имя модуля, приоритет, уровень, пользовательское сообщение строки, исключение с трассировкой стека);

Уникальный номер: Реализуйте TraceListener (см. System.Diagnostics), который добавляет этот уникальный номер, не заставляйте вызывающий код генерировать его.

Имя модуля: Трассировка стека предоставит такие подробности - при условии, что вы знаете, какой код в каком модуле. На самом деле это, вероятно, не имеет значения с точки зрения поиска неисправностей.

Приоритет: API-интерфейс System.Diagnostics обеспечивает следующий уровень серьезности. Информация, предупреждение и ошибка (а также отладка). Теперь приоритет находится в глазах смотрящего, с точки зрения развития - это либо «эй, это случилось, вы, возможно, хотели бы знать (информация)», он «это выглядит немного странно, если мы можем продолжить в любом случае (предупреждение) "и" о черт, я сломан (ошибка) ".

Слой: Какова реальная разница между модулем и ошибкой здесь? Еще раз, если вы правильно используете System.Diagnostics, можно динамически добавлять информацию об окружающей среде, например, на каком компьютере это произошло. Вы бы не хотели, чтобы разработчики делали это последовательно.

Пользовательское сообщение: Да, это разумно. Для получения бонусных баллов используйте форматную строку (фактически - Trace.TraceError / TraceWarning / TraceInformation уже делают это. Так что просто используйте это.

Исключение: Если вы используете Trace.TraceError (et.al), тогда вы можете использовать строку формата. Не каждая ошибка имеет исключение, поэтому вам не обязательно создавать API, который их принимает, если они принимают строку формата - вы можете сделать это:

Trace.TraceError ( «Пользователь предоставил следующий ввод« {0} ». Следующее исключение: \ r \ n {1}», UserInput, бывший );

В любом случае - я думаю, что я говорю о том, что если вы пишете это в .NET так, как будто вы это делаете - потратьте полдня на просмотр документации System.Diagnostics. Вы можете отрицать необходимость написания своего API.

0 голосов
/ 03 января 2013

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

0 голосов
/ 31 марта 2009

Если это приложение ASP.NET, то вам следует изучить Мониторинг состояния ASP.NET . Даже по умолчанию он отправляет подробные трассировки в журнал событий. Вы можете настроить его так, чтобы он выводил те же выходные данные в XML-файлах, а также добавлять свою собственную трассировку.

0 голосов
/ 31 марта 2009

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

0 голосов
/ 31 марта 2009

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

0 голосов
/ 31 марта 2009

У меня есть два замечания:

  1. Мне не нравится полагаться на временные метки в качестве уникальных идентификаторов. Если вы точно знаете, что ваш сайт не будет загружен, это нормально, но в условиях сильного стресса разрешение в миллисекундах может быть недостаточным. Причина в том, что счетчик миллисекунд может иметь гранулярность больше единицы. Это означает, что два очень близких вызова могут получить одну и ту же метку времени. Не очень вероятно, но зачем себя ограничивать?

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

...