Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Лекция 2. Наследование.doc
Скачиваний:
5
Добавлен:
15.11.2019
Размер:
273.92 Кб
Скачать

Обработка исключений

В течение множества лет обработка ошибок превращалась разработчиками, использующими Windows, в сложную смесь различных приемов. Множество программистов реализовывало свою собственную логику обработки ошибок в рамках одно-го-единственного конкретного приложения. Например, команда разработчиков могла определить свой набор констант для представления известных условий возникновения ошибок и использовать их как значения, возвращаемые методами. Помимо этого в Windows API было определено большое количество кодов ошибок, которые должны были обрабатываться при помощи #define, HRESULTS и множества прочих средств. Многие СОМ-разработчики использовали набор стандартных СОМ-интерфейсов для возвращения значимой информации об ошибках клиентам СОМ.

Очевидная проблема всех этих приемов обработки ошибок заключается в том, что все они — разные. Каждый прием привязан к конкретной технологии, конкретному языку или конкретному проекту. Чтобы наконец навести порядок во всем этом, .NET предлагает единую технику для обнаружения ошибок времени выполнения и передачи сообщений о них: это — структурированная обработка исключений (Structured Exception Handling, SEH).

Преимущества этого метода заключаются в том, что в распоряжение всех разработчиков предоставляется единый и хорошо продуманный подход к обработке ошибок, который к тому же является общим для всех языков .NET. Таким образом, разработчик, использующий С#, будет реализовывать обработку ошибок точно так же, как программист, использующий VB.NET или МС++, и все остальные разработчики, использующие платформу .NET. Разработчики также получают дополнительную возможность генерировать и перехватывать исключения между двоичными файлами, AppDomains (о них будет сказано — в главе 6) и компьютерами в независимом от языка стиле.

Для того чтобы понять, как применять исключения в С#, в первую очередь необходимо осознать, что исключения в С# —^это объектьь_Все системные и пользовательские исключения в С# производятся от класса System Exception (который, в свою очередь, производится от класса System Object). В табл. 3.1 представлен перечень наиболее интересных свойств класса Exception.

Жизненный цикл объектов

В С# общий принцип управления памятью формулируется очень просто: для создания объекта в области «управляемой кучи» (managed heap) используется ключевое слово new. Среда выполнения .NET автоматически удалит объект тогда, когда он больше не будет нужен. Правило в целом вполне понятно, однако возникает один дополнительный вопрос: а как среда выполнения определяет, что объект больше не нужен? Короткий (то есть неполный) ответ гласит, что среда выполнения удаляет объект из памяти, когда в текущей области видимости больше не остается активных ссылок на этот объект. Например:

// Создаем локальный объект класса Саг

public static int Main(string[ ] args)

{

// Помещаем объект класса Саг в управляемую кучу

Саг сЗ = new Car(“Viper", 200, 100);

. . . .

return 0;

} // Если сЗ - единственная ссылка на этот объект, то начиная с этого момента

//он может быть удален

Предположим, что в вашем приложении создано (размещено в оперативной памяти) три объекта класса Саг. Если в управляемой куче достаточно места, мы получим три активные ссылки — по одной на каждый объект в оперативной памяти. Каждая такая активная ссылка на объект в памяти называется также корнем (root). To, ч го у нас получилось, схематически представлено на рис. 3.21.

Рис. 3.21. Ссылки указывают на местонахождение объектов в управляемой куче

Если вы занимаетесь только тем, что создаете все новые и новые объекты, в конце концов пространство в управляемой куче закончится. В ситуации, когда свободного места в управляемой куче больше нет, а вы пытаетесь создать новый объект, будет сгенерировано исключение OutOfMemoryException. Поэтому, если вы хотите создать код приложения, совершенно исключив возможность возникновения ошибок, создавать объекты можно следующим образом (в реальных приложениях так обычно не поступают):

// Создаем объекты Саг таким образом, чтобы отреагировать на возможную нехватку места //в управляемой куче

public static int Main(string[ ] args)

{

. . . .

Car yetAnotherCar;

try

{

yetAnotherCar = new Car( );

}

catcht(OutOfMemoryException e)

{

Console.WriteLine(e.Message);

Console.WriteLine(“Managed heap is FULL1 Running GC ..");

}

return 0;

}

Вне зависимости от того, насколько осторожно вы будете создавать объекты, как только место в управляемой куче заканчивается, автоматически запускается сборщик мусора (garbage collector, GC). Сборщик мусора оценивает все объекты, размещенные в настоящий момент в управляемой куче, с точки зрения того, есть ли в области видимости приложения активные ссылки на них. Если активных ссылок на какой-либо объект больше нет или объект установлен в null, этот объект помечается для удаления, и в скором времени память, занимаемая подобными обьектами, высвобождается.