Ода ошибкам и исключениям

Ода ошибкам и исключениям

Вне зависимости от того, что говорит нам наша (часто преувеличенная) самооценка, абсолютно идеальных программистов не существует. Создание программного обеспечения является сложным делом и поэтому даже самые лучшие программы могут иметь проблемы. Иногда причиной проблем бывает несовершенный: программный код (например, выход за границы массива). В других случаях проблема возникает из-за неправильных данных, вводимых пользователем (например, ввод имени в поле телефонного номера), если возможность обработки таких данных не была предусмотрена в приложении. Независимо от причин возникающих проблем, результатом всегда оказывается непредусмотренное поведение приложения. Чтобы очертить рамки нашего обсуждения структурированной, обработки исключительных ситуаций, позвольте сформулировать определения трех терминов, часто используемых при изучении соответствующих аномалий.

Программные ошибки. Это, попросту говоря, ошибки программиста. Например, при использовании языка C++ без управляемых расширений, если вызвать указатель NULL или забыть очистить выделенную память (в результате чего происходит 'утечка" памяти), то возникает программная ошибка.

Пользовательские ошибки. В отличие от программных ошибок, пользовательские ошибки обычно возникают в результате действий объекта, использующего приложение, а не в результате действий разработчика. Например, действия пользователя, который вводит в текстовый блок строку "неправильного вида", могут привести к возникновению ошибки, если ваш программный код не в состоянии обработать такой ввод.

Исключения. Исключения, или исключительные ситуации, обычно проявляются в виде аномалий среды выполнения, и очень трудно, если вообще возможно, полностью учесть их все в процессе программирования приложения. К возможным исключительным ситуациям относятся попытки соединиться с базой данных, которой больше не существует, открыть поврежденный файл, контактировать с компьютером, который выключен. Программист, как и конечные пользователи, имеют очень ограниченные возможности управления в подобных "исключительных обстоятельствах".

С учетом данных определений должно быть ясно, что структурированная обработка исключений в .NET предлагает подход, предназначенный для выявления исключительных ситуаций в среде выполнения. Однако и в случае программных и пользовательских ошибок, которые ускользнули от вашего внимания, среда CLR зачастую генерирует соответствующее исключение, идентифицирующее проблему. Для этого библиотеки базовых классов .NET определяют целый ряд исключений, таких как FormatException, IndexOutOfRangeException, FileNotFoundException, ArgumentOutOfRangeExсeption и т.д.

Перед тем как углубиться в детали, давайте определим формальную роль структурированной обработки исключений и выясним, чем такая обработка отличается от традиционного подхода в деле исправления ошибок.

Замечание. Чтобы сделать примеры программного кода, используемые в данной книге, как можно более конкретными, в них обрабатываются не асе возможные исключения, генерируемые соответствующими методами из библиотек базовых классов. Приемы, представленные в этой главе, вы можете использовать в своих реальных проектах по своему усмотрению.

Поделитесь на страничке

Следующая глава >

Похожие главы из других книг

Правило 8: Не позволяйте исключениям покидать деструкторы

Из книги Эффективное использование C++. 55 верных способов улучшить структуру и код ваших программ автора Мейерс Скотт

Правило 8: Не позволяйте исключениям покидать деструкторы C++ не запрещает использовать исключения в деструкторах, но это, безусловно, очень нежелательная практика. На то есть серьезная причина. Рассмотрим пример:class Widget {public:...~Widget() {...} // предположим, здесь есть


14. Предпочитайте ошибки компиляции и компоновки ошибкам времени выполнения

Из книги Стандарты программирования на С++. 101 правило и рекомендация автора Александреску Андрей

14. Предпочитайте ошибки компиляции и компоновки ошибкам времени выполнения РезюмеНе стоит откладывать до выполнения программы выявление ошибок, которые можно обнаружить при ее сборке. Предпочтительно писать код, который использует компилятор для проверки инвариантов


62. Не позволяйте исключениям пересекать границы модулей

Из книги Разработка ядра Linux автора Лав Роберт

62. Не позволяйте исключениям пересекать границы модулей РезюмеНе бросайте камни в соседский огород — поскольку нет повсеместно распространенного бинарного стандарта для обработки исключений С++, не позволяйте исключениям пересекать распространяться между двумя


Нахождение исполняемых образов с изменениями приводящими к ошибкам

Из книги автора

Нахождение исполняемых образов с изменениями приводящими к ошибкам Обычно полезно знать, в какой версии исходных кодов ядра появился дефект. Если известно, что дефект появился в версии 2.4.18, но его не было в версии 2.4.17, то сразу появляется ясная картина изменений, которые