Код, демонстрирующий важность Принужденного региона Выполнения
Не упоминается, но может помочь в некоторых случаях:
var xhr = new XMLHttpRequest();
xhr.onreadystatechange = function() {
if (xhr.readyState !== 4) return;
if (xhr.status === 200) {
var doc = iframe.contentWindow.document;
doc.open();
doc.write(xhr.responseText);
doc.close();
}
}
xhr.open('GET', url, true);
xhr.send(null);
5 ответов
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 когда-либо будет выполнен).
Хотя у меня нет конкретного примера для вас, я думаю, что вы упускаете смысл попробовать .. наконец заблокировать внутри методов, которые гарантируют успех. Вся суть в том, что метод всегда будет успешным, означает, что в отношении того, что (исключение) происходит во время выполнения, будут предприняты шаги, чтобы гарантировать, что данные, к которым осуществляется доступ, будут в допустимом состоянии, когда метод вернется. Без попытки ... в конце концов, вы ничего не добьетесь, и это может означать, что произойдет только половина операций, которые вы хотели бы выполнить. Таким образом, Cer.Success на самом деле не гарантирует успеха, он только заявляет, что вы, как разработчик, гарантируете успех.
Посетите эту страницу для объяснения различий между состояниями Success и MayFail, поскольку это относится к Array.CopyTo метод: http: // блоги. asp.net/justin_rogers/archive/2004/10/05/238275.aspx[1217 visible
Атрибуты CER являются средствами документации. Они действительно влияют на то, как CLR будет выполнять код в некоторых ситуациях, но я считаю, что они (или их отсутствие) никогда не приведут к ошибке в текущих версиях .NET.
Они в основном «зарезервированы для использования в будущем».
Первичный драйвер для этой функции должен был поддерживать строгие требования SQL-серверов для интеграции CLR в SQL Server 2005. Вероятно, чтобы другие могли использовать и, вероятно, по юридическим причинам эта глубокая интеграция была опубликована как хостинг API, но технические требования были SQL Server. Помните, что в SQL Server MTBF измеряется месяцами, а не часами, и перезапуск процесса из-за необработанного исключения совершенно неприемлем.
Эта статья журнала MSDN , вероятно, лучшая из тех, что я видел, описывая технические требования, для которых создана среда с ограничениями.
ReliabilityContract используется для украшения ваших методов, чтобы указать, как они работают с точки зрения потенциально асинхронных исключений (ThreadAbortException, OutOfMemoryException, StackOverflowException). Ограниченная область выполнения определяется как раздел catch или finally (или fault) блока 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 с ней происходят 2 вещи. Метод будет предварительно подготовлен JIT, поэтому он не будет вызывать JIT-компилятор при первом запуске, который может попытаться использовать саму память и вызвать собственные исключения. Также, находясь внутри CER, среда выполнения обещает не генерировать исключение ThreadAbort и будет ждать сгенерированного исключения до тех пор, пока CER не завершится.
Итак, вернемся к вашему вопросу; Я все еще пытаюсь придумать простой пример кода, который прямо ответит на ваш вопрос.
Вы запускаете образец MSDN под отладчиком? Я не думаю, что CER может работать, когда вы выполняете в отладчике, поскольку сам отладчик все равно меняет характер выполнения.
Если вы создаете и запускаете приложение в режиме оптимизированного выпуска, вы должны иметь возможность увидеть, как это не удастся.