Net framework 5, а также среды Visual Studio 2012 и C#

ПриМеЧание
Можно.возразить,.что.информация.о.месте.возникновения.ошибки.важнее.сведений.
о.ее.содержании .Например,.полезнее.было.бы.знать,.что.перевод.денег.со.счета.не.
произошел,.а.не.то,.что.метод.Transfer.не.сработал.из-за.исключения.SecurityException.
или.OutOfMemoryException .На.самом.деле,.модель.обработки.ошибок.Win32.дей-
ствует.следующим.способом:.методы.возвращают.значение.true.или.false,.указывая.
на.результативность.своей.работы .Это.дает.вам.информацию.о.том,.какой.именно.
метод.стал.причиной.проблемы .Затем,.если.в.программе.предусмотрен.поиск.ин-
формации.о.причинах.сбоя,.вызывается.метод.GetLastError .В.классе.System Exception.
присутствует.свойство.Source,.указывающее.имя.незавершенного.метода .Но.это.
свойство.принадлежит.к.типу.String,.поэтому.вам.придется.самостоятельно.анализи-
ровать.полученные.данные .К.тому.же.в.ситуации,.когда.два.метода.вызывают.один.и.
тот.же.метод,.свойство.Source.не.поможет.вам.понять,.где.именно.произошел.сбой .
Вместо.этого.придется.анализировать.строку,.возвращенную.свойством.StackTrace.
класса.Exception .Из-за.всех.этих.сложностей.я.пока.еще.не.встречал.программиста,.
написавшего.подобный.код 
Существуют несколько подходов, 
способных
сгладить проблему испорченного 
состояния:
‰
CLR запрещает аварийно завершать потоки во время выполнения кода блоков 
catch
и 
finally
. Поэтому сделать метод 
Transfer
более устойчивым можно 
следующим способом:
public static void Transfer(Account from, Account to, Decimal amount) {
try { /* здесь ничего не делается */ }
finally {
from -= amount;
// Прерывание потока (из-за Thread.Abort/AppDomain.Unload)
// здесь невозможно
to += amount;
}
}
Тем не менее я настоятельно не рекомендую помещать весь код внутрь 
блоков 
finally
! Этот прием можно использовать только для изменения самых 
чувствительных состояний.
‰
Класс 
System.Diagnostics.Contracts.Contract
позволяет применять к методам 
контракты кода. Именно они позволяют проверять аргументы и другие пере-

---

522