Проверяйте все данные из внешних источников

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

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

«Garbage in, garbage out». Возможно, эту их школьную поговорку следует перевести нашей студенческой: «Каков стол, таков и стул». — Прим. перев.

Решите, как обрабатывать неправильные входные данные Что делать, если вы обнаружили неверный параметр? В зависимости от ситуации вы можете выбрать один из дюжины подходов, подробно описанных в разделе 8.3.

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

Защита от проблем, кажущихся несущественными, может иметь большее значение, чем можно подумать (рис. 8-1). В оставшейся части этой главы я расскажу о проверке данных из внешних источников, проверке входных параметров и обработке неправильных входных данных.

Рис. 8-1. Часть плавучего моста Interstate-90 в Сиэтле затонула во время шторма, потому что резервуары были оставлены открытыми. Они наполнились водой, и мост стал слишком тяжел, чтобы держаться на плаву. Обеспечение защиты от мелочей во время проектирования может значить больше, чем кажется.

Утверждения

Утверждение (assertion) — это код (обычно метод или макрос), используемый во время разработки, с помощью которого программа проверяет правильность своего выполнения. Если утверждение истинно, то все работает так, как ожидалось.

Если ложно — значит, в коде обнаружена ошибка. Например, если система предполагает, что длина файла с информацией о заказчиках никогда не будет превышать 50 000 записей, программа могла бы содержать утверждение, что число записей меньше или равно 50 000. Пока это число меньше или равно 50 000, утверждение будет хранить молчание. Но как только записей станет больше 50 000, оно громко провозгласит об ошибке в программе.

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

Обычно утверждение принимает два аргумента: логическое выражение, описывающее предположение, которое должно быть истинным, и сообщение, выводимое в противном случае. Вот как будет выглядеть утверждение на языке Java, если переменная denominator должна быть ненулевой:

Пример утверждения (Java)

assert denominator /= 0: "denominator is unexpectedly equal to 0.";

В этом утверждении объявляется, что denominator не должен быть равен 0.

Первый аргумент — denominator /= 0 — логическое выражение, принимающее значение true или false. Второй — это сообщение, выводимое, когда первый аргумент равен false (т. е. утверждение ложно).

Используйте утверждения, чтобы документировать допущения, сделанные в коде, и чтобы выявить непредвиденные обстоятельства. Например, утверждения можно применять при проверке таких условий:

• ¦ значение входного (выходного) параметра попадает в ожидаемый интервал;
• ¦ файл или поток открыт (закрыт), когда метод начинает (заканчивает) выполняться;
• ¦ указатель файла или потока находится в начале (конце), когда метод начинает (заканчивает) выполняться;
• ¦ файл или поток открыт только для чтения, только для записи или для чтения и записи;
• ¦ значение входной переменной не изменяется в методе;
• ¦ указатель ненулевой;
• ¦ массив или другой контейнер, передаваемый в метод, может вместить по крайней мере X элементов;
• ¦ таблица инициализирована для помещения реальных значений;
• ¦ контейнер пуст (заполнен), когда метод начинает (заканчивает) выполняться;
• ¦ результаты работы сложного, хорошо оптимизированного метода совпадают с результатами метода более медленного, но написанного яснее.

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

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

Создание собственного механизма утверждений

Многие языки программирования, включая C++, Java, и Microsoft Visual Basic, имеют встроенную поддержку утверждений. Если ваш язык не поддерживает процедуры утверждений напрямую, их легко написать. Стандартный макрос тем языка, а не просто assert языка C++ не предусматривает вывода текстового сообщения.

Вот пример улучшенного макроса ASSERT на C++:

Пример макроса утверждения (C++)

#define ASSERT(condition, message) { \

if (!(condition)) { \

LogError(" Assertion failed: ", \

«condition, message); \

exit(EXIT_FAILURE); \

} \

}

Общие принципы использования утверждений

Далее перечислены общие положения по применению утверждений.

Используйте процедуры обработки ошибок для ожидаемых событий и утверждения для событий, которые происходить не должны

Утверждения проверяют условия событий, которые никогда не должны происходить. Обработчик ошибок проверяет внештатные события, которые могут и не происходить слишком часто, но были предусмотрены писавшим код программистом и должны обрабатываться и в промышленной версии. Обработчик ошибок обычно проверяет некорректные входные данные, утверждения — ошибки в программе.

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

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

Старайтесь не помещать выполняемый код в утверждения

Если в утверждении содержится код, возникает возможность удаления этого кода компилятором при отключении утверждений. Допустим, у вас есть следующее утверждение:

Пример опасного использования утверждения (Visual Basic)

Debug.Assert(PerformAction()) ‘Невозможно выполнить действие

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

Пример безопасного использования утверждения (Visual Basic)

actionPerformed = PerformAction()

Debug.Assert(actionPerformed) ‘Невозможно выполнить действие

Используйте утверждения для документирования и проверки предусловий и постусловий

Предусловия и постусловия — это часть подхода к проектированию и разработке программ, известному как «проектирование по контракту» (Meyer, 1997). При использовании пред- и постусловий каждый метод или класс заключает контракт с остальной частью программы.

Предусловия — это соглашения, которые клиентский код, вызывающий метод или класс, обещает выполнить до вызова метода или создания экземпляра объекта. Предусловия — это обязательства клиентского кода перед кодом, который он вызывает.

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

Утверждения — удобный инструмент для документирования пред- и постусловий.

С этой целью можно использовать и комментарии, но в отличие от них утверждения могут динамически проверять, выполняются ли пред- и постусловия.

В следующем примере утверждения документируют пред- и постусловия в функции Velocity:

Пример использования утверждений для документирования пред- и постусловий (Visual Basic)

Private Function Velocity (_

ByVal latitude As Single, _

ByVal longitude As Single, _

ByVal elevation As Single _

) As Single

‘ Предусловия

Debug.Assert (-90 <= latitude And latitude <= 90)

Debug.Assert (0 <= longitude And longitude <= 360)

Debug.Assert (-500 <= elevation And elevation <= 75000)

…

‘ Постусловия

Debug.Assert (0 <= returnVelocity And returnVelocity <= 600)

‘Возвращенное значение

Velocity = returnVelocity

End Function

Если бы переменные latitude, longitude и elevation поступили из внешнего источника, корректность их значений должна была быть проверена и обработана в коде обработчика ошибок, а не с помощью утверждений. Но если эти переменные поступили из доверенного внутреннего источника, а метод спроектирован в предположении, что их значения будут в разрешенном интервале, то применение утверждений допустимо.

Для большей устойчивости кода проверяйте утверждения, а затем все равно обработайте возможные ошибки

Каждая потенциально ошибочная ситуация обычно проверяется или утверждением, или кодом обработчика ошибок, но не тем и другим вместе. Некоторые эксперты утверждают, что необходим только один тип проверки (Meyer, 1997).

Однако реальные программы и проекты бывают слишком запутанными, чтобы можно было полагаться на одни лишь утверждения. В больших, долгоживущих системах различные части могут разрабатываться несколькими проектировщиками 5-10 лет и более. Разработка будет производиться в разное время и в разных версиях продукта. Эти проекты будут основаны на разных технологиях и сосредоточены на различных вопросах разработки системы. Проектировщики могут быть удалены друг от друга географически, особенно если элементы системы приобретались у независимых компаний. Программисты будут использовать различные стандарты кодирования в разное время жизни системы. В большой команде разработчиков некоторые неминуемо будут добросовестнее других, поэтому часть кода будет проверяться более тщательно, чем остальная. В любом случае, когда тестовые команды работают в нескольких географических регионах, а требования бизнеса приводят к изменению тестового покрытия от версии к версии, рассчитывать на всестороннее низкоуровневое тестирование системы нельзя.

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

Вот как это можно сделать на примере функции Velocity:

Пример использования утверждений для документирования пред- и постусловий (Visual Basic)

Private Function Velocity (_

ByRef latitude As Single, _

ByRef longitude As Single, _

ByRef elevation As Single _

) As Single

‘Предусловия

Так выглядит код утверждения.

Debug.Assert (-90 <= latitude And latitude <= 90)

Debug.Assert (0 <= longitude And longitude <= 360)

Debug.Assert (-500 <= elevation And elevation <= 75000)

…

‘Откорректируйте входные данные. Значения должны попадать в интервалы,

‘указанные в вышестоящих утверждениях. Иначе они будут заменены

‘ближайшими допустимыми значениями.

Таким может быть код, обрабатывающий неверные входные данные во время выполнения программы.

If (latitude <-90) Then

latitude = -90

ElseIf (latitude >90) Then

latitude = 90

End If

If (longitude <0) Then

longitude = 0

ElseIf (longitude >360) Then

longitude = 360

End If

If (elevation <-500) Then

elevation = -500

ElseIf (elevation >75000) Then

elevation = 75000

End If

Способы обработки ошибок

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

Рассмотрим эти приемы подробней.

Вернуть нейтральное значение

Иногда наилучшей реакцией на неправильные данные будет продолжение выполнения и возврат заведомо безопасного значения. Численные расчеты могут возвращать 0. Операция со строкой может вернуть пустую строку, а операция с указателем — пустой указатель. Метод рисования в видеоигре, получивший неправильное исходное значение цвета, может по умолчанию использовать цвет фона или изображения. Однако в методе рисования рентгеновского снимка ракового больного вряд ли стоит применять «нейтральное значение». В таких случаях лучше прекратить выполнение программы, чем показать пациенту неправильные результаты.

Заменить следующим корректным блоком данных

Условия обработки потока данных иногда таковы, что следует просто вернуть следующие допустимые данные. Если при чтении информации из базы данных встречена испорченная

запись, можно просто продолжить считывание, пока не будут найдены корректные данные. Если вы считываете показания термометра 100 раз в секунду и один раз не получили достоверного измерения, можно просто подождать 1/100 секунды и обратиться к следующему показанию.

Вернуть тот же результат, что и в предыдущий раз

Если программа считывания показаний термометра один раз не получила измерение, она может просто вернуть то же значение, что и в предыдущий раз. В зависимости от приложения, температура скорее всего не сильно изменится за 1/100 секунды. Если в видеоигре запросу на прорисовку части экрана передано неверное значение цвета, вы можете просто вернуть тот же цвет, что и раньше. Но, авторизуя транзакции в банкомате, вы, пожалуй, не захотите использовать «то же значение, что и в предыдущий раз» — ведь это будет номер счета предыдущего клиента!

Подставить ближайшее допустимое значение

В некоторых случаях вы можете вернуть ближайшее допустимое значение, как выше в примере функции Velocity. Часто это обоснованный подход для получения показаний откалиброванных инструментов. Так, термометр мог бы быть откалиброван от 0 до 100 градусов по Цельсию. Если вы получаете значение меньше 0, можно заменить его на 0, как ближайшее допустимое значение. Если же значение больше 100, можно подставить 100. Если в операции со строкой ее длина заявлена меньшей 0, можно принять ее за 0. Мой автомобиль использует этот подход к обработке ошибок, когда я двигаюсь задним ходом. Так как спидометр не показывает отрицательную скорость, то при езде задним ходом, скорость просто равна 0 — ближайшему допустимому значению.

Записать предупреждающее сообщение в файл

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

Вернуть код ошибки

Вы можете решить, что только определенные части системы будут обрабатывать ошибки. Другие же не будут обрабатывать ошибки локально, а будут просто сообщать, что обнаружена ошибка, и надеяться, что какой-либо другой вышестоящий в иерархии вызовов метод эту ошибку обработает. Конкретный механизм оповещения остальной системы об ошибке может быть следующим:

• ¦ установить значение статусной переменной;
• ¦ вернуть статус в качестве возвращаемого значения функции;
• ¦ сгенерировать исключение, используя встроенный в язык программирования механизм обработки исключений.

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

Вызвать процедуру или объект — обработчик ошибок

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

Этот подход может очень серьезно повлиять на безопасность. Если в программе возникнет переполнение буфера, злоумышленник сможет узнать адрес метода (объекта)-обработчика. Таким образом, при переполнении буфера во время работы приложения использовать этот способ небезопасно.

Показать сообщение об ошибке, где бы она ни случилась

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

Обработать ошибку в месте возникновения наиболее подходящим способом

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

Такой подход предоставляет разработчикам большую гибкость. Однако он таит в себе опасность, что система в целом не будет удовлетворять требованиям корректности и устойчивости (см. ниже). А в зависимости от того, какой в конечном итоге будет реакция на ошибку, этот метод может привести к потенциальному расползанию кода пользовательского интерфейса по системе. Это приведет к тем же проблемам, что и в случае с выводом сообщений об ошибках.

Прекратить выполнение

Некоторые системы прекращают работу при возникновении любой ошибки. Этот подход оправдан в приложениях, критичных к безопасности. Например, какая реакция на ошибку будет наилучшей, если ПО, контролирующее радиационное оборудование для лечения рака, получит некорректное значение радиационной дозы? Надо ли использовать то же значение, что и в предыдущий раз? А может, ближайшее допустимое или нейтральное значение?

В этом случае остановка работы — наилучший вариант. Мы охотнее предпочтем перезагрузить машину, чем рискнуть применить неправильную дозу.

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

Устойчивость против корректности

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

Устойчивость требует всегда пытаться сделать что-то, что позволит программе продолжить работу, даже если это приведет к частично неверным результатам.

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

В потребительских приложениях устойчивость, напротив, предпочтительнее корректности. Какой-то результат всегда лучше, чем прекращение работы. Текстовый редактор, которым я пользуюсь, временами показывает последнюю на экране строку лишь частично. Хочу ли я, чтобы при обнаружении этой ситуации редактор завершал выполнение? Нет: когда я в следующий раз нажму Page Up или Page Down, экран обновится, и изображение исправится.

Влияние выбора метода обработки ошибок на проектирование высокого уровня

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

Выбор общего подхода к работе с некорректными данными — это вопрос архитектуры или высокоуровневого проектирования, и он должен быть рассмотрен на одном из этих этапов разработки системы.

Выбрав подход, придерживайтесь его неукоснительно. Если вы решили обрабатывать ошибки на высоком уровне, а в низкоуровневом коде просто сообщать о них, удостоверьтесь, что высокоуровневый код действительно их обрабатывает!

Некоторые языки позволяют игнорировать возвращаемое функцией значение (в C++ вы не обязаны что-то то делать с возвращенным результатом), но не игнорируйте информацию об ошибке! Проверяйте значение, возвращаемое из функции.

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

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

Исключения

Исключение — это специальное средство, позволяющее передать в вызывающий код возникшие ошибки или исключительные ситуации. Если код в некотором методе встречает неожиданную ситуацию и не знает, как ее обработать, то он генерирует исключение, т. е. фактически умывает руки со словами: «Я не знаю, что с этим делать, надеюсь, кто-нибудь другой знает, как на это реагировать!» Код, не имеющий понятия о контексте ошибки, может вернуть управление другой части системы, которая, возможно, лучше знает, как интерпретировать ошибку и сделать с ней что-то осмысленное.

Кроме того, исключения могут быть полезны для упрощения запутанной логики участка кода, как в примере «Переписать с помощью try-finally». Вот принцип действия исключений: метод, применяя оператор throw, создает объект-исключение. Код какого-либо другого метода, стоящего выше в иерархии вызовов, перехватит это исключение в блоке try-catch.

Популярные языки программирования по-разному реализуют исключения (табл. 8.1):

Табл. 8-1. Поддержка исключений в популярных языках программирования

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

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

Основное преимущество исключений состоит в их способности сигнализировать об ошибке так, что ее нельзя проигнорировать (Meyers, 1996). При других подходах к обработке ошибок есть вероятность, что сбойная ситуация останется незамеченной. Исключения устраняют такую возможность.

Генерируйте исключения только для действительно исключительных ситуаций Применение исключений должно быть зарезервировано только для действительно исключительных случаев — иначе говоря, для ситуаций, которые нельзя реализовать другими методами кодирования. Исключения используются в таких же обстоятельствах, как и утверждения: для событий, которые не просто редко происходят, а которые никогда не должны случаться.

Исключения представляют собой компромисс между возможностью обработки непредвиденных ситуаций, с одной стороны, и повышением сложности — с другой. Исключения ухудшают инкапсуляцию, требуя от кода, вызывающего метод, знать, какие исключения могут быть сгенерированы внутри него. Это усложняет код, что противоречит Главному Техническому Императиву ПО (см. главу 5), суть которого в снижении сложности.

Дата добавления: 2014-01-07