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

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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