Время C# наконец выполнения

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

Судя по опубликованному вами описанию, поскольку Исключение никогда не перехватывается, оно передается вызывающей стороне, проходит вверх по стеку, в конечном итоге не обрабатывается, вызов завершается, а затем вызывается блок finally.

Фактически, выводится обработчик исключений CLR по умолчанию. Обработчики исключений возникают перед блоком finally. После блока finally CLR завершается из-за необработанного исключения (она не может завершиться раньше, поскольку C # гарантирует [1], что вызывается предложение finally).

Я бы сказал, что это просто стандартное поведение, обработка исключений происходит до того, как наконец.

[1] гарантируется при нормальной работе, по крайней мере, при отсутствии внутренних ошибок времени выполнения или отключения электроэнергии

Думаю, эта статья поможет вам более подробно понять, что здесь происходит.

http://bartdesmet.net/blogs/bart/archive/2006/04/04/clr -exception-handle-from-a-to-z-everything-you-didn-t-want-to-know-about-try-catch-finally-fault-filter.aspx

Чтобы добавить больше в смесь, примите во внимание следующее:

using System;
namespace OddThrow
{
    class Program
    {
        static void Main()
        {
            AppDomain.CurrentDomain.UnhandledException +=
                delegate(object sender, UnhandledExceptionEventArgs e)
            {
                Console.Out.WriteLine("In AppDomain.UnhandledException");
            };
            try
            {
                throw new Exception("Exception!");
            }
            catch
            {
                Console.Error.WriteLine("In catch");
                throw;
            }
            finally
            {
                Console.Error.WriteLine("In finally");
            }
        }
    }
}

Что в моей системе (норвежский язык) показывает это:

[C:\..] ConsoleApplication5.exe
In catch
In AppDomain.UnhandledException

Ubehandlet unntak: System.Exception: Exception!
   ved OddThrow.Program.Main() i ..\Program.cs:linje 24
In finally

Команда try / finally без уловки будет использовать обработчик по умолчанию, который делает именно то, что вы видите. Я использую его все время, например, в тех случаях, когда обработка исключения покрывает ошибку, но вы все еще хотите выполнить некоторую очистку.

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

Хотя это не совсем ожидаемо, программа все же ведет себя должным образом. Не ожидается, что блок finally будет запускаться первым, он будет запускаться всегда.

Я скорректировал ваш пример:

public static void Main()
{
    try
    {
        Console.WriteLine("Before throwing");
        throw new Exception("Exception!");
    }
    finally
    {
        Console.WriteLine("In finally");
        Console.ReadLine();
    }
}

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

Блоки try-catch-finally работают точно так, как вы ожидали , если они обнаруживаются в какой-то момент . Когда я написал для этого тестовую программу и использую различные уровни вложенности, единственный случай, когда она вела себя так, как вы описали, - это когда исключение было полностью не обработано кодом, и оно перешло в операционную систему.

Каждый раз, когда я его запускал, сообщение об ошибке создавала ОС. Таким образом, проблема заключается не в C #, а в том, что ошибка, не обрабатываемая пользовательским кодом, больше не находится под контролем приложения , и поэтому среда выполнения (я считаю) не может заставить шаблон выполнения в теме.

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

EDIT

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

Чтобы собрать пару ответов вместе, происходит следующее: как только у вас возникает необработанное исключение, в AppDomain возникает событие UnhandledExceptionEvent, после чего код продолжает выполняться (то есть, наконец). Это статья MSDN о мероприятии

Следующая попытка:

1. Я считаю, что этот случай не упоминается в стандарте C #, и согласен, что он почти противоречит ему.

2. Я считаю, что внутренняя причина того, что это происходит, примерно так: CLR регистрирует свой обработчик исключений по умолчанию как обработчик SEH в FS: [0] когда в вашем коде больше уловок, эти обработчики добавляются в цепочку SEH. В качестве альтернативы, только обработчик CLR вызывается во время обработки SEH и обрабатывает цепочку исключений CLR изнутри, я не знаю, какой именно.

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

Обработчик исключений по умолчанию знает, что в стеке нет зарегистрированных обработчиков исключений. Поэтому сначала он вызывает все зарегистрированные обработчики UnhandledException, затем выводит сообщение об ошибке и отмечает AppDomain для выгрузки.

Только после этого начинается развертывание стека и, наконец, вызываются блоки согласно стандарту C #.

Насколько я понимаю, способ обработки необработанного исключения в CLR не рассматривается в стандарте C #, только порядок, в котором функции finally вызываются во время развертывания стека. Этот порядок сохраняется. После этого "Последствия такого прерывания определяются реализацией". пункт вступает в силу.