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

ВниМание
Используя.описанный.подход,.мы.обманываем.вызывающий.код.в.двух.отношениях .
Во-первых,.мы.искажаем.информацию.о.том,.что.пошло.не.так .В.нашем.примере.файл.
не.удалось.найти,.но.мы.сообщили.о.невозможности.найти.имя .Во-вторых,.мы.пере-
даем.неверную.информацию.о.месте.сбоя .Если.бы.исключение.FileNotFoundException.
могло.пробиться.наверх.стека.вызовов,.его.свойство.StackTrace.говорило.бы,.что.
ошибка.произошла.в.конструкторе.FileStream .Но.когда.мы.поглощаем.это.исклю-
чение.и.генерируем.новое.NameNotFoundException,.трассировка.стека.укажет,.что.
ошибка.произошла.в.блоке.catch,.то.есть.на.расстоянии.нескольких.строк.кода.от.
места.генерирования.исключения .Это.может.серьезно.затруднить.отладку,.поэтому.
описанный.подход.следует.использовать.с.осторожностью 
А теперь предположим, что тип 
PhoneBook
был реализован чуть иначе. Пусть он 
поддерживает открытое свойство 
PhoneBookPathname
, позволяющее пользователю 
задавать или получать имя и путь к файлу, в котором нужно искать номер телефо-
на. Поскольку пользователь знает, что данные телефонного справочника берутся 
из файла, я модифицирую метод 
GetPhoneNumber
так, чтобы он не перехватывал 
никакие исключения, а выпускал их за пределы метода. Заметьте: я меняю не па-
раметры метода 
GetPhoneNumber
, а способ его абстрагированного представления 
пользователям типа 
PhoneBook
. В результате пользователи будут ожидать, что путь 
предусмотрен контрактом 
PhoneBook
.
Иногда генерирование нового исключения после перехвата уже имеющегося 
преследует целью добавление к исключению новых данных или контекста. Однако 
эта цель достигается намного проще. Достаточно перехватить исключение нужного 
вам типа, добавить в коллекцию его свойства 
Data
требуемую информацию и сге-
нерировать его заново:
private static void SomeMethod(String filename) {
try {
// Какие-то операции }
catch (IOException e) {
продолжение


---

532