Любые ошибки в программах — это результат нестабильностей.Как правило, для фатального невыполнения задачи недостаточноодной нестабильности — они возникают последовательно, одна задругой, в конечно счете и приводя к невозможности решения задачи.
Развивая анализ нестабильностей, подробно остановлюсь на том, какие нестабильности первого рода существуют и как их можно предотвращать. В базовом обзоре я отметил, что эти нестабильности связаны с передачей некорректных параметров в функции и методы, и что вызываемая функция должна ассертировать (а по возможности — еще и корректно обрабатывать) ситуацию, давая разумный отклик на выходе.
Какие варианты “неправильной” передачи наиболее распространены? Во первых, передаваемые параметры могут являться базовыми элементами (переменные, константы, указатели на массивы и т.п.), во вторых, передаваемые аргументы могут быть сложными структурами или экземплярами классов. В разных случаях возможны разные варианты обработки.
Более сложные примеры возможной нестабильности уже требуют проникновения в детали вызываемой функции. Допустим, мы реализовали алгоритм для расчёта минимальной ограничивающей сферы по множеству точек. Сходу можно придумать варианты нестабильностей первого рода:
- множество точек, переданное на вход в функцию — пустое;
- множество точек состоит из одной точки;
- множество точек таково, что все точки находятся в одном месте пространства;
- множество точек таково, что внутренние переменные и буфера (зависит от алгоритма и деталей его реализации) могут переполнится.
Как минимум, первые 2 варианта легко ассертируются на входе в функцию. Но, учитывая, что время работы данного алгоритма сильно больше, чем начальные проверки, я бы рекомендовал сделать проверки и адекватный отклики в остальных случаях. Например, в случае передачи множества точек, состоящего из одной точки, построить сферу радиуса epsilon с центром в указанной точке, и т.д.
Для более сложных аргументов наиболее распростраенный вариант — это передача экземпляра класса, который находится в некорректном состоянии своей стейт-машины. Стейт-машины и нестабильности второго рода я ещё буду рассматривать подробнее, пока что ограничусь тем, что если передается экземпляр объекта и у него должно быть заранее известное состояние, то это проверяется соответствующей информационной функцией (пояснение будет в следующем посте).
То, что нестабильности надо ассертировать — как мне кажется, вообще вопросов не доложно вызывать. Но вот задача выбора простого ассертирования vs проверки и обработки всегда проблематична. Особенно если речь заходит про time-critical функции, которые вызываются много раз на фрейме. В таких случаях приходится анализировать не только саму вызываемую функцию, но еще и рассматривать потенциальные варианты, откуда могли придти невалидные данные.
Вообще если говорить про источник ошибочных данных, то можно выделить следующие основные классы:
- Ошибочные данные, которые прошли из внешних источников (файл, TCP/IP пакет и т.п.). Сюда же относятся: прерывания, эвенты от внешнего железа и другие асинхронные события;
- Ошибочные данные, которые были введены пользователем;
- Ошибочные данные, которые были получены в результате ошибки алгоритма;
- Ошибочные данные, которые были получены в результате отсутствия обработки вызываемых функций (типа вызвали CreateFile(), не проверили INVALID_HANDLE_VALUE).
При этом первый и второй вариант группируются в понятие “внешний источник”, третий и четвертый — в “ошибки программы” (такие ошибки программ приводят к появлению нестабильностей третьего рода).
Если аргумент на входе функции является косвенно или явно, аргументом внешнего источника, такое должно быть в обязательном порядке обработано на входе в функцию. Ассертировать такие аргументы даже нет смысла (хотя и можно для удобства отладки), поскольку это не программистская ошибка. А вот обеспечить логгирование — обязательно надо.
Лирическое отступление — программы, которые падают при чтении битого файла — не редкость. Но мне известно еще и программы, которые падают при отсутствии в системе звуковой карты или DVD привода!!!
Впрочем, если ваша функция является глубоко внутренней по отношению к данным внешнего источника, то можно переложить работу о проверке таких данных на вызывающую вас функцию. То есть фактически перевести ошибу категории “ошибка внешнего источника” в ошибку категории “программные”. Только надо не забыть написать в документации, что вы не потерпите невалидных данных и мужественно уроните программу, если вам передать что-то неправильное.
Вообще из всех рассмотренных вариантов источников ошибочных данных единственный “приятный” вариант ошибки — это третий пункт (ошибки алгоритма). Поскольку только он потенциально (да и то не всегда) является воспроизводимым при последовательных запусках приложения. Все остальное ошибки как правило глубоко запрятаны в системе и когда именно они станут причиной аварийного завершения программы — никому неизвестно.
Две проблемы с передачей аргументов стоят особняком: это аргументы с обязательным требованием на время жизни и возможность версионирования данных. Первая проблема описана здесь, один из способов решения второй проблемы можно увидеть в WinAPI вариантах — это sizeof(struct) или первое поле с mask на заполненные/используемые поля.
Общее резюме: нестабильности первого рода проявляются в тех случаях, когда в функцию передаются невалидные данные. Источник невалидных данных может быть либо внешним по отношению к программе (железо, человек, файл), либо находиться внутри вызвавшего функцию программного кода.
В первом случае обязательной является корректная обработка события (желательно с логгированием). Во втором случае — как минимум должно быть ассертирование события, как максимум: ассерт + корректная обработка. Необходимость обоих действий определяется программистом исходя из следующих факторов: сложность или длительность диагностики / обработки, возможность для функции выдать адекватный отклик на невалидные входные данные, потенциальная допустимость возникновения нестабильности третьего рода в продакшен-версии.
cross-posted to blog.gamedeff.com
Теория ошибок является до смешного кратким введением в программирование. Все основные и второстепенные положения Теории проверены автором на практике и на коллегах, за что отдельное спасибо их вдовам и сиротам.
«Ошибки так же неисчерпаемы, как и атом»
Приписывается Карлу Марксу и его подельникам
Аксиома. В любой программе есть ошибки.
Следствие 1. В программе, состоящей из одного оператора, есть ошибки.
Следствие 2. В программе, состоящей из N операторов, есть по крайней мере N ошибок.
Следствие 3. В программе, состоящей из одного оператора, есть по крайней мере N ошибок.
Следствие 4. В любой программе содержится бесконечное число ошибок.
Следствие 5. Чтобы познать бесконечность, нужно быть не философом, а программистом.
Закон взаимосвязи программ и ошибок.
Для того, чтобы получить ошибки, надо написать программу.
Для того, чтобы получить программу, надо стараться избегать ошибок.
Следствие. Что бы вы ни делали — у вас будут получаться только ошибки.
Теорема обратимости программ и ошибок.
Всегда можно придумать программу, в которой будет не менее N ошибок.
И наоборот, всегда можно придумать ошибку, которая есть не менее, чем в N программах.
Чем более программа необходима, тем больше в ней ошибок и наоборот.
Следствие 1. Совершенно ненужная программа ошибок не содержит.
Следствие 2. Ненужную программу невозможно создать ни за какие деньги.
Правило неоднозначности программ.
Даже две совершенно одинаковые программы содержат разные ошибки.
Народная примета. Сколько программистов — столько и программ.
Наблюдения системного администратора. Сколько программ — столько и неправильных результатов.
Фундаментальный закон Теории ошибок. На ошибках учатся.
Следствие 1. Программист, написавший программу, становится ученым.
Следствие 2. Чем больше программист делает ошибок, тем быстрее он становится ученым.
Следствие 3. По-настоящему ученый программист никогда не пишет правильных программ.
Замечание. На то он и ученый.
Указание начинающему программисту.
Если вы с первого раза сумели написать программу, в которой компилятор не обнаружил ни одной ошибки, сообщите об этом системному программисту. Он исправит ошибки в компиляторе.
Наблюдение системного программиста.
Если начинающий программист написал программу, которая сразу заработала, значит она состоит только из комментариев.
Закон находимости ошибок.
Программист может обнаружить ошибку только в чужой программе или не обнаружить нигде.
Следствие 1. Администратор не может обнаружить ошибку.
Следствие 2. Ошибке не все равно кто ее обнаружит.
Следствие 3. Индивидуальная программистская деятельность невозможна.
Закон неприкосновенности ошибок.
Ошибку можно наблюдать, но нельзя исправить.
Исправление очевидной ошибки превращает ее в неочевидную (недоступную для наблюдения), причем этот процесс необратим.
Следствие 1. Любое активное действие, призванное улучшить программу, ухудшает программу.
Следствие 2. Пассивное наблюдение улучшает программу.
Следствие 3. Чем больше в программе очевидных ошибок, тем точнее можно предсказать результат ее работы.
Замечание. Программа без очевидных ошибок — неработоспособна.
Следствие 4. Программу проще написать заново, чем исправить.
Закон общественной полезности программиста.
Каждый человек на Земле должен быть программистом.
Совет начинающему программисту.
Никогда не исправляйте найденных ошибок, ибо это повлечет за собой появление неизвестного числа ненайденных. Лучше опишите их в сопроводительной документации как особенность программы.
1) Не следует делить очевидные ошибки на постоянные и исчезающие, а следует делить их на обнаруженные ранее, обнаруженные ранее и забытые, и на новые, которые обычно являются хорошо забытыми старыми.
2) Объектное программирование — надежное средство для написания необнаруживаемых ошибок.
Закон невозможности совершения ошибки.
Получить нужную ошибку искусственным путем невозможно.
Доказательство: Программируя нужную ошибку, вы допустите другую ошибку, в корне меняющую превоначальный замысел.
Следствие. Программирование с необходимыми ошибками — искусство.
Теорема о невозможности доказательства правильности программ.
Нельзя доказать, что программа не имеет ошибок.
Док-во: Не нужно доказывать, что в программе есть ошибки.
Компьютерный вирус — маленькая живучая ошибка, у которой в результате мутации появились ноги и рот.
Настоящий программист, давший клятву Гиппократа, не станет мучать компьютерный вирус. Он либо сделает вид, что не узнал его, либо незаметно для окружающих быстро пересадит его в свой компьютер.
Определение. Будем называть языком ошибок правила, в обход которых пишутся программы.
Более точное определение. Будем называть языком ошибок высокого уровня правила, по которым пишутся программы на языках высокого уровня.
Следствие. Чем ниже уровень базового языка программирования, тем ошибки более машинно-ориентированы.
Синтаксис языка ошибок определяется синтаксисом базовой системы программирования.
Ошибки могут следовать друг за другом. От перестановки двух эквивалентных ошибок результат не меняется (коммутативность эквивалентных ошибок).
Две последовательные ошибки можно объединить в одну, более сильную.
Не любую сильную ошибку можно разбить на две более слабых.
Неделимая ошибка называется устранимой. Установить, что ошибка неделима невозможно.
Одинаковые ошибки необязательно делать каждый раз, достаточно сделать одну, а затем лишь обращаться к ней по мере необходимости из любого места программы.
Передача управления от одной ошибки к другой может осуществляться как по определенному условию, так и безусловно (в последнем случае ошибка называется безусловной).
Ошибки могут образовывать циклы. Наиболее устойчивый из них бесконечный.
Ошибки могут вызывать друг друга и сами себя (рекурсивность ошибок).
Ошибки могут размножаться.
Невероятно, но некоторые ошибки могут исчезать. К счастью — ненадолго.
Ошибки допускают многократное вложение друг в друга.
Две одинаковые вложенные ошибки называются четной ошибкой и ошибкой не являются.
Свойство четности ошибок. Если написанная программа сработала правильно, то это значит, что во время ее работы выполнилось четное число ошибок или программист не понял задания.
Следствие. Чтобы получать правильные результаты, следует в каждой ветви программы предусмотреть четное число ошибок.
Наблюдение программиста, полезное для юмориста.
Ошибка, повторенная дважды, перестает быть ошибкой.
Некоторые ошибки сами могут содержать ошибки (не путать с четными ошибками). В такие минуты у неопытного программиста может сложиться впечатление, что его программа работает правильно. Опытные программисты активно используют такие моменты во время приемо-сдаточных испытаний.
Определение глобальности ошибок.
Ошибка называется глобальной, если поглощает все локальные по отношению к ней ошибки.
Закон экономии ошибок.
Чем более глобальную ошибку вы допустите, тем меньше будет общее число действующих ошибок.
Пример. Предположим в некоторой подпрограмме Sub1 вы допустили 257 ошибок. В головной программе Main вы допустили всего 13 ошибок, но лишь одна из них является глобальной по отношению к ошибкам процедуры Sub1, т.к. в результате ее срабатывания процедура Sub1 стирается из памяти и удаляется с диска.
Далее, пусть в операционной системе вашего компьютера есть две ошибки. Одна из них является глобальной по отношению к написанной вами программе Main, т.к. загружает вашу программу в виртуальное пространство, привязанное к несуществующей плате памяти.
И, наконец, в самом компьютере находится единственная, но наиболее глобальная по отношению к остальным ошибка в распайке фазового и земляного проводов, сводящая первоначальное число ошибок 257 к одной — глобальной и притом легко обнаруживаемой во время первого включения.
ВЗАИМОДЕЙСТВИЕ ОШИБОК С ОПЕРАЦИОННОЙ СИСТЕМОЙ
Во время исполнения ошибки имеют наивысший приоритет.
Прервать исполнение ошибки может только другая, более активная ошибка.
Запросы операционной системы к ошибкам ошибками могут игнорироваться.
Запросы ошибок к операционной системе игнорироваться не могут.
При работе с файлами ошибки могут пользоваться файловой системой ОС и ее ошибками.
На компьютере с параллельной архитектурой может выполняться несколько ошибок одновременно.
На компьютере с потоковой архитектурой очередная ошибка запускается по готовности на ее входах данных, переданных другими ошибками.
Машина искуственного интеллекта способна сама удовлетворять свою потребность в ошибках.
Системные программы облегчают процесс написания прикладных программ и их ошибок.
Определение. Тестирование — это процесс нахождения ошибок в тесте.
Хороший тест должен содержать ошибки, компенсирующие их нехватку в тестируемой программе.
Программа — отладчик, предназначенная для нахождения ошибок в любых программах (и в самой себе в том числе), содержит ошибки.
Закон полноты языка.
Если в языке программирования есть только одно тонкое место, делающее язык уязвимым для ошибок, то именно оно будет использоваться программистами наиболее часто.
Закон вызываемости подпрограмм.
Если в какой-либо подпрограмме есть ошибки, то эта подпрограмма будет вызываться наиболее часто. Если же какая-либо подпрограмма никогда не вызывается, значит она не содержит ошибок.
Объектно-ориентированный редактор, призванный уберечь программиста от синтаксических ошибок, позволяет вносить в программу весьма хитроумные ошибки, которые не удается обнаружить ни транслятором, ни отладчиком. Обычный текстовый редактор таких возможностей не предоставляет.
Программа — транслятор, предназначенная для перевода программ с языка высокого уровня на машинный язык, при переводе сама порождает ошибки. Ошибки, которые содержались в исходном описании, переводятся безошибочно.
Аккуратные и опытные программисты делают глубокие и хорошо продуманные ошибки. Современные языки программирования предоставляют аккуратным и опытным программистам для этого широкие возможности.
Заключительный совет всем, кто до него добрался.
До начала работы над проектом следует тщательно продумать все необходимые ошибки и связи между ними. Это значительно упростит работу над ошибками в самом проекте.
Следствие. Хорошо продуманные ошибки залог надежной работы проектируемой программы.
Совет руководителю среднего звена.
В любой программе должны быть устранимые ошибки (т.е. хорошо отлаженные неправильные участки программы, изъятие которых не влечет за собой появления большого числа неустранимых ошибок), которые будут в определенной последовательности устраняться во время приемо-сдаточных испытаний для создания видимости отладки. Такие ошибки следует программировать наиболее тщательно.
Закон неизменности хороших привычек.
У каждого программиста есть любимые ошибки, которые он всегда делал, делает, и не собирается отказываться от них в будущем.
В программах, написанных программистами-женщинами, логических ошибок значительно меньше.
Закон массовых чисел.
Среди большого числа различных чисел всегда можно выбрать необходимое.
Следствие из закона массовых чисел.
Чтобы получить правильный результат необходимо распечатать как можно больше различных результатов и среди них выбрать необходимый.
Пример вероятного события.
Если в комнате, где установлено много терминалов, находится достаточное количество обезъян, то есть вероятность, что через достаточно большое, но конечное время компьютер будет оснащен операционной системой Unix.
ВЫВОД ИЗ ТЕОРИИ ОШИБОК
Положив, что энтропия программы, не содержащей ошибок, равна бесконечности (что справедливо, т.к. понятие «Правильная программа» абстрактное), можно создать необычайно устойчивую и стремящуюся к самоорганизации систему, если в ее основе будет лежать Теория ошибок. Понятно, что это единственный путь для создания программ, дающих предсказуемые результаты (и вообще, результаты).
Автор считает, что Теория ошибок послужит надежным фундаментом для бурно развивающейся кибернетики.