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

using System;
using System.Runtime.CompilerServices;
using System.Runtime.ConstrainedExecution;

class Program {
    static bool cerWorked;

    static void Main( string[] args ) {
        try {
            cerWorked = true;
            MyFn();
        }
        catch( OutOfMemoryException ) {
            Console.WriteLine( cerWorked );
        }
        Console.ReadLine();
    }

    unsafe struct Big {
        public fixed byte Bytes[int.MaxValue];
    }

    //results depends on the existance of this attribute
    [ReliabilityContract( Consistency.WillNotCorruptState, Cer.Success )] 
    unsafe static void StackOverflow() {
        Big big;
        big.Bytes[ int.MaxValue - 1 ] = 1;
    }

    static void MyFn() {
        RuntimeHelpers.PrepareConstrainedRegions();
        try {
            cerWorked = false;
        }
        finally {
            StackOverflow();
        }
    }
}

Когда MyFn подвергается джиттингу, он пытается создать ConstrainedRegion из блока finally.

• В случае без ReliabilityContract не может быть сформирована надлежащая ConstrainedRegion, поэтому генерируется обычный код. Исключение переполнения стека возникает при вызове Stackoverflow (после выполнения блока try).

• В случае с ReliabilityContract может быть сформирована ConstrainedRegion, а требования к стеку методов в блоке finally могут быть подняты в MyFn. Исключение переполнения стека теперь возникает при вызове MyFn (до того, как будет выполнен блок try).

Основным драйвером для этой функциональности была поддержка строгих требований SQL Server для интеграции CLR в SQL Server 2005. Вероятно, для того, чтобы другие могли использовать и, вероятно, по юридическим причинам, эта глубокая интеграция была опубликована как хостинг API, но технические требования были SQL Servers. Помните, что в SQL Server MTBF измеряется в месяцах, а не в часах, и перезапуск процесса из-за возникновения необработанного исключения совершенно неприемлем.

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

ReliabilityContract используется для украшения ваших методов, чтобы указать, как они работают с точки зрения потенциально асинхронных исключений (ThreadAbortException, OutOfMemoryException, StackOverflowException). Область ограниченного выполнения определяется как раздел catch или finally (или сбой) блока try, которому непосредственно предшествует вызов System.Runtime.CompilerServices.RuntimeServices.PrepareConstrainedRegions().

System.Runtime.CompilerServices.RuntimeServices.PrepareConstrainedRegions();
try 
{
    // this is not constrained
} 
catch (Exception e) 
{
    // this IS a CER
} 
finally 
{
    // this IS ALSO a CER
}

Когда метод ReliabilityContract используется внутри CER, с ним происходят две вещи. Метод будет предварительно подготовлен JIT, чтобы он не вызывал JIT-компилятор при первом выполнении, который может попытаться использовать саму память и вызвать собственные исключения. Также, находясь внутри CER, среда выполнения обещает не генерировать исключение ThreadAbort и будет ждать, чтобы генерировать исключение, пока не завершится CER.

Итак, вернемся к вашему вопросу; Я все еще пытаюсь придумать простой пример кода, который прямо ответит на ваш вопрос. Однако, как вы, возможно, уже догадались, для простейшего примера потребуется довольно много кода, учитывая асинхронный характер проблемы, и, скорее всего, это будет код SQLCLR, поскольку именно в этой среде CER будут использоваться с наибольшей выгодой.

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

Если вы создадите и запустите приложение в оптимизированном режиме выпуска, вы сможете увидеть его сбой.

Хотя у меня нет конкретного примера для вас, я думаю, что вы упускаете смысл попробовать блокировать try..finally внутри методов, гарантирующих успех. Весь смысл утверждения, что метод всегда будет успешным, означает, что в отношении того, что (исключение) происходит во время выполнения, будут предприняты шаги, чтобы гарантировать, что данные, к которым осуществляется доступ, будут в допустимом состоянии, когда метод вернется. Без попытки... в конце концов, вы бы ничего не гарантировали и могли бы означать, что произойдет только половина операций, которые вы хотели. Таким образом, Cer.Success на самом деле не гарантирует успеха, он лишь утверждает, что вы, как разработчик, гарантируете успех.

Посетите эту страницу для объяснения различий между состояниями Success и MayFail в отношении метода Array.CopyTo: http://weblogs.asp.net/justin_rogers/archive/2004/10/05/238275.aspx

Атрибуты CER являются средством документирования. Они влияют на то, как CLR будет выполнять код в некоторых ситуациях, но я считаю, что они (или их отсутствие) никогда не приведут к ошибке в текущих версиях .NET.

В основном они «зарезервированы для использования в будущем».