Что вы делаете, если ваша регистрация ошибок завершается сбоем, и как вы проверяете, работает ли она в рабочей среде?

Question

1. Что вы делаете, если у вас происходит сбой кода регистрации ошибок?
2. Как вы можете убедиться, что он в данный момент работает?
3. Как вы узнаете, что это не работает?
4. Как вы проверяете, что это работает в производственной среде?
5. Должен ли я выдавать исключение, если все остальное терпит неудачу?

Приведенный ниже код использует прикладной блок ведения журнала корпоративной библиотеки Microsoft.Как вы делаете это "лучше"?

using Microsoft.Practices.EnterpriseLibrary.Logging;

class Program
{
    static void Main(string[] args)
    {
        try
        {
            // Trying to write some data to the DB
            ...
        }
        catch (Exception ex)
        {
            LogHelper.LogException(ex, "Trying to write to the DB");
        }
    }
}

public class LogHelper
{
    public static void LogException(Exception ex, string exceptionType)
    {
        try
        {
            // Simplified version, only logging the message
            Logger.Write(exceptionType);
        }
        catch
        {
            // What do you do here???
        }
    }
}

Answer 1

Смотрите ответы в моем связанный с этим вопрос:

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

В этом конкретном (исключительном) случае проглатывание исключения является единственным способом не завершать работу приложения.

Answer 2

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

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

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

Получение большей отказоустойчивости, чем это, стоило бы усилий только для чрезвычайно критически важных приложений, ИМХО.

Answer 3

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