Читайте также:
|
private void SomeMethod() {
try {
// Внутрь блока try помещают код, требующий корректного
// восстановления работоспособности или очистки ресурсов.
}
catch (InvalidOperationException) {
// В такие блоки catch помещают код, который должен восстанавливаться
// после исключений типа InvalidOperationException (или любого исключения,
// производного от него).
}
catch (IOException) {
// В такие блоки catch помещают код, который должен восстанавливаться // после исключений типа IOException (или любого исключения, // производного от него).
catch {
// В такие блоки catch помещают код, который должен
// восстанавливаться после исключений любого типа.
// После перехвата исключений их, как правило,
// генерируют повторно.
throw;
}
finally {
// Внутрь блоков finally помещают код, выполняющий очистку ресурсов после любых действий, начатых в блоке try. Код из этого блока исполняется ВСЕГДА независимо от того, было исключение или нет.
}
// Код после блока finally исполняется, если в блоке try не было исключения или если исключение было перехвачено блоком catch и не было сгенерировано то же самое или другое исключение.)
«Допустим, у меня есть приложение, которое должно считать из файла структуру размером в 20 байт, но файл оказался лишь 10-байтовым. В этом случае я не ожидаю встретить конец файла при чтении, но это неожиданно происходит. Наверное, здесь должно возникнуть исключение, не так ли?» Фактически большинство файлов содержит структурированные данные. Довольно редко бывает так, что приложение читает из файла байт за байтом, тут же обрабатывая прочитанные байты, пока не достигнет конца файла. Поэтому я думаю, логичнее будет, если при попытке чтения за пределами файла метод Read всегда будет генерировать исключение.
При разработке типа вы сначала пытаетесь представить себе разнообразные ситуации, в которых будет применяться тип. Сначала определяется имя типа — обычно существительное, например FileStream (файловый поток) или StringBuilder (построитель строк), затем приступают к определению членов (типов данных свойств, параметров методов, возвращаемых значений и т. п.). Особенности определения этих членов становятся программным интерфейсом типа. Эти члены действия обычно обозначаются глаголами — Read (считать), Write (записать), Flush (очистить), Append (присоединить), Insert (вставить), Remove (удалить) и т. п. Если член, обозначающий действие, не может выполнить свою задачу, он должен сгенерировать исключение.
Есть масса причин, по которым вызванный метод может сгенерировать исключение:
■ если недостаточно памяти в стеке, генерируется исключение Stack-Overflowlixception\
■если не удается обнаружить сборку, в которой определен тип, генерируется исключение PileNotFoundException-,
■если IL-код метода не поддается верификации, генерируется исключение VetificationException;
■если недостаточно памяти для JIT-компиляции IL-кода, генерируется исключение OutOJMemoryException.
Фильтрация исключений среды выполнения
Перехватываемые и обрабатываемые исключения можно отфильтровать либо по типу, либо по некоторым критериям, определяемым пользователем.
Обработчики с фильтрацией по типу управляют определенным типом исключения (или производные из этого типа классы).В следующем примере показан обработчик с фильтрацией по типу, позволяющий перехватить определенное исключение, в данном случае исключение FileNotFoundException.
catch(FileNotFoundException e)
{
Console.WriteLine("[Data File Missing] {0}", e);
}
Обработчики с пользовательской фильтрацией перехватывают и обрабатывают исключения на основе требований к исключению, определяемых пользователем.
ThreadAbortException - Исключение, выдаваемое при вызове метода Abort. Этот класс не может наследоваться.
При вызове метода Abort для уничтожения потока, общеязыковая среда выполнения выдает исключение ThreadAbortException. Исключение ThreadAbortException является особым исключением, которое может быть перехвачено, но снова возникает в конце блока catch. При возникновении этого исключения среда выполнения перед тем, как завершить поток, выполняет все блоки finally. Так как поток может выполнять код в блоках finally неограниченное время или вызывать метод Thread.ResetAbort для отмены аварийного завершения потока, нет гарантии, что поток когда-либо закончит работу. Чтобы дождаться окончания работы прерванного потока можно вызвать метод Thread.Join. Вызов метода Join является блокирующим, возврата не происходит до действительного окончания выполнения потока.
Когда среда CLR останавливает фоновые потоки после того, как все потоки переднего плана в управляемом исполняемом файле завершились, метод Thread.Abort не используется. Следовательно, нельзя использовать перехват исключения ThreadAbortException для обнаружения прерывания фоновых потоков средой CLR.
Дата добавления: 2015-01-30; просмотров: 68 | Поможем написать вашу работу | Нарушение авторских прав |