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

Глава.20 .Исключения.и.управление.состоянием
блоки 
try
/
finally
создаются автоматически. Компилятор строит эти блоки и при 
переопределении деструктора класса (метод 
Finalize
). При работе с упомянутыми 
конструкциями написанный вами код помещается в блок 
try
, а код очистки — в блок 
finally
. А именно:
‰
если вы используете инструкцию 
lock
, то внутри блока 
finally
снимается 
блокировка;
‰
если вы используете инструкцию 
using
, то внутри блока 
finally
для объекта 
вызывается метод 
Dispose
;
‰
если вы используете инструкцию 
foreach
, то внутри блока 
finally
для объекта 
IEnumerator
вызывается метод 
Dispose
;
‰
если вы определяете деструктор, то внутри блока 
finally
вызывается метод 
Finalize
базового класса.
Например, в следующем коде на C# используются возможности инструкции 
using
. Хотя этот фрагмент короче предыдущего, при обработке исходного текста 
этого и предыдущего примеров компилятор генерирует идентичный код:
using System;
using System.IO;
internal sealed class SomeType {
private void SomeMethod() {
using (FileStream fs =
new FileStream(@"C:\Data.bin", FileMode.Open)) {
// Вывод частного от деления 100 на первый байт файла
Console.WriteLine(100 / fs.ReadByte());
}
}
}
Подробнее об инструкции 
using
мы поговорим в главе 21, а об инструкции 
lock
— в главе 30.
не надо перехватывать все исключения
Распространенная ошибка — слишком частое и неуместное использование бло-
ков 
catch
. Перехватывая исключение, вы тем самым заявляете, что ожидали его, 
понимаете его причины и знаете, как с ним разобраться. Другими словами, вы 
определяете политику для приложения. Эта тема подробно раскрыта в разделе 
«Продуктивность вместо надежности».
Тем не менее слишком часто приходится видеть примерно такой код:
try {
// Попытка выполнить код, который, как считает программист,
// может привести к сбою...
}

---

527
Приемы.работы.с.исключениями
catch (Exception) {
...
}
Этот код демонстрирует, что в нем предусмотрены 
все
исключения 
любых
типов 
и он способен восстанавливаться после 
любых
исключений в 
любых
ситуациях. 
Разве это возможно? Тип из библиотеки классов ни в коем случае не должен пере-
хватывать все исключения подряд: ведь он не может знать наверняка, как при-
ложение должно реагировать на исключения. Кроме того, такой тип будет часто 
вызывать код приложения через делегата, виртуальный метод или интерфейсный 
метод. Если в одной части приложения возникает исключение, то в другой части, 
вероятно, есть код, способный перехватить его. Исключение должно пройти через 
фильтр перехвата и быть передано вверх по стеку вызовов, чтобы код приложения 
смог обработать его как надо.
Если исключение осталось необработанным, CLR завершает процесс. О необ-
работанных исключениях мы поговорим чуть позже. Большинство из них обнару-
живаются на стадии тестирования. Для борьбы с ними следует либо заставить код 
реагировать на определенное исключение, либо переписать его, устранив условия, 
ставшие причиной сбоя. Число необработанных исключений в окончательной 
версии программы, предназначенной для выполнения в производственной сре-
де, должно быть минимальным, а сама программа должна быть исключительно 
устойчивой.