Обработка исключений в рамках Исключения в C#

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

Дайте ему всплыть и обработайте его попыткой верхнего уровня. /ловить.

Вы можете добавить блок try-catch в свой catch ] также блок.

У Криса С. есть лучший ответ. Размещение блока try-catch внутри блока catch очень редко бывает хорошей идеей. и в вашем случае он просто свернет ваш код. Если вы проверите, успешно ли вы записали в файл журнала здесь, вам придется делать это везде, где вы пытаетесь записать в файл журнала. Вы можете легко избежать этого ненужного дублирования кода, если все ваши отдельные модули будут автономными, когда дело доходит до уведомления / обработки ошибок в этих модулях. При сбое отправки почты вы выполняете необходимые действия внутри блока catch для обработки этого исключительного состояния, например:

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

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

Лично я решаю эту ситуацию с помощью простого метода расширения.

public static class MyExtentions
{
    public static void LogToErrorFile(this Exception exception)
    {
        try
        {
            System.IO.File.AppendAllText(System.IO.Path.Combine(Application.StartupPath, "error_log.txt"),
                String.Format("{0}\tProgram Error: {1}\n", DateTime.Now, exception.ToString()));
        }
        catch 
        { 
            // Handle however you wish
        }
    }
}

Использование простое:

try
{
   ...
}
catch(Exception ex)
{
   ex.LogToErrorFile();
}

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

Каждое исключение перехватывается только внутри блока try-catch. Вы можете вложить пробную ловушку, но, как правило, это не лучшая идея.

• Во-первых, я бы посоветовал не ловить "Exception" в блоке catch. Вместо этого вы можете для рассылки проверить всю достоверность, а затем перехватить конкретное исключение (SmtpException), с которым вы можете что-то сделать (и проинформировать пользователя с помощью дружественного сообщения). Выбрасывать исключение из вашего кода и сообщать об этом пользовательскому интерфейсу - неплохая идея. Если ваши методы принимают входные данные с определенной спецификацией и если они не выполняются, ваш метод должен / может выдать ошибку и сообщить об этом пользователю.

• Для исключений, которые не контролируются, используйте исключение глобальной обработки, например Application_Error для Интернета. Получение лучшей информации о необработанных исключениях Питер Бромберг объясняет это лучше.

• Также для любого привилегированного ресурса, к которому вы обращаетесь, например журналов событий, убедитесь, что ваша сборка имеет к нему доступ.

• Полезные ссылки Создание действительно полезного механизма обработки исключений ASP.NET Питер А. Бромберг а также Документирование выдающихся разработчиков Питер А. Бромберг Для веб-приложения загляните в Мониторинг работоспособности Ведение журнала исключений

• И еще кое-что, если ваше приложение выходит из строя / выдает ошибку, которая не может обработать (вообще), лучше не продолжать работу и не продолжать. Приложение в нестабильном состоянии - не лучшая идея.

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

private void SendMail()
{
    try
    {
        //i try to send a mail and it throws an exception
    }
    catch(Exception ex)
    {
        WriteToLog();
    }
}

private void WriteToLog()
{
    try
    {
        // Write to the Log
    }
    catch(Exception ex)
    {
        // Error Will Robinson
        // You should probably make this error catching specialized instead of pokeman error handling
    }
}