Основным драйвером для этой функции была поддержка строгих требований SQL Server для интеграции CLR в SQL Server 2005. Вероятно, чтобы другие могли использовать и, вероятно, по юридическим причинам, эта глубокая интеграция была опубликована как API хостинга, но технические требования были SQL-серверы. Помните, что в SQL Server значение MTBF измеряется месяцами, а не часами, и перезапуск процесса из-за возникновения необработанного исключения совершенно неприемлем.
Эта статья MSDN Magazine , вероятно, лучшая из тех, что я видел, описывающих технические требования, для которых была создана ограниченная среда исполнения.
ReliabilityContract используется для украшения ваших методов, чтобы указать, как они работают в условиях потенциально асинхронных исключений (ThreadAbortException, OutOfMemoryException, StackOverflowException). Ограниченная область выполнения определяется как секция catch или finally (или error) блока 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 для большей выгоды.