Какие существуют типы ошибок программах

Отладка программы призвана выискивать «вредителей» кода и устранять их. За это отвечают отладчик и журналирование для вывода сведений о программе.

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

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

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

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

Синтаксические ошибки

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

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

Семантические ошибки

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

Рассмотрим данный пример:

3 + 5 * 6

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

3 + 5, заключенные в скобки, дадут желаемый результат, а именно 48.

Ошибки в процессе выполнения

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

Вот хороший пример:

input = 25
x = 0.8/(Math.sqrt(input) — 5)

Фрагмент кода выше будет скомпилирован успешно, но input 25 приведет к ZeroDivisionError. Это ошибка во время выполнения. Другим популярным примером является StackOverflowError или IndexOutofBoundError. Важно то, что вы идентифицируете эти ошибки и узнаете, как с ними бороться.

Существуют ошибки, связанные с тем, как ваш исходный код использует память и пространство на платформе или в среде, в которой он запущен. Они также являются ошибками во время выполнения. Такие ошибки, как OutOfMemoryErrorand и HeapError обычно вызваны тем, что ваш исходный код использует слишком много ресурсов. Хорошее знание алгоритмов поможет написать код, который лучше использует ресурсы. В этом и заключается отладка программы.

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

Отладка программы

Вот несколько советов о том, как правильно выполнять отладку:

• Использовать Linters. Linters – это инструменты, которые помогают считывать исходный код, чтобы проверить, соответствует ли он ожидаемому стандарту на выбранном языке программирования. Существуют линты для многих языков.
• Превалирование IDE над простыми редакторами. Вы можете выбрать IDE, разработанную для языка, который изучаете. IDE – это интегрированные среды разработки. Они созданы для написания, отладки, компиляции и запуска кода. Jetbrains создают отличные IDE, такие как Webstorm и IntelliJ. Также есть NetBeans, Komodo, Qt, Android Studio, XCode (поставляется с Mac), etc.
• Чтение кода вслух. Это полезно, когда вы ищете семантическую ошибку. Читая свой код вслух, есть большая вероятность, что вы зачитаете и ошибку.
• Чтение логов. Когда компилятор отмечает Error, обязательно посмотрите, где он находится.

Двигаемся дальше

Поздравляем! Слово «ошибка» уже привычно для вас, равно как и «отладка программы». В качестве новичка вы можете изучать кодинг по книгам, онлайн-урокам или видео. И даже чужой код вам теперь не страшен 🙂

В процессе кодинга измените что-нибудь, чтобы понять, как он работает. Но будьте уверены в том, что сами написали.

Викторина

input = Hippo’
if input == ‘Hippo’:
print ‘Hello, Hippo’

Ответы на вопросы

2. Синтаксическая ошибка: Отсутствует стартовая кавычка в первой строке.

Кто-то из великих мыслителей когда-то сказал: «Покажите мне человека, который не ошибся ни разу в жизни, и я покажу вам человека, который ничего не достиг». Сами по себе ошибки — это не зло, они помогают нам расти и развиваться. Совершить их может специалист любого уровня. Однако учиться лучше на чужих неудачах, нежели на своих. «Библиотека программиста» детально разобралась в этой теме и составила список распространенных ошибок кодеров, которых вы можете избежать, если дочитаете статью до конца. Поехали!

Приступать к программированию, не до конца проработав схему проекта

Реализацию любого проекта можно разделить на три простых этапа:

• Анализ требований проектируемого продукта
• Создание схемы или прототипа самого проекта
• Реализация или непосредственное написание кода

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

Отсутствие единообразия и формата написания кода

Это ошибка, которую чаще всего совершают неопытные разработчики и новички.

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

Написание глупых или заумных комментариев

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

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

Однако при комментировании нужно знать меру. Не стоит писать философское эссе размером в страницу, все должно быть четко, лаконично и по существу.

Не тестировать написанное

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

Написание универсальных супер-функций

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

Плохие сообщения коммитов

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

Фиксации с сообщениями типа: «Исправлена ​​ошибка» или «Обновлена ​​функция» — так себе названия. Хороший коммит содержит информацию о проблеме и ее решении, предшествующий уникальному идентификатору токена (если он доступен).

Чрезмерная инженерия или усложнение простых вещей

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

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

Не анализировать готовые решения в сети

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

Консерватизм и проповедование только одного стека

Поговорка, про кулика, расхваливающего свое болото актуальна и для мира ИТ. Наверняка, вам также доводилось слышать, как некоторые специалисты превозносят одну конкретную технологию, говоря, что все остальные ужасны. И заголовки кликбейтных статей, увещевающих о войнах фреймворков и языков («Vue vs React» или «Python vs Java») рождаются именно по их вине. Нельзя говорить, что один популярный инструмент хуже другого только лишь потому, что вы к нему привыкли. В разных ситуациях каждый будет хорош по-своему. Здесь главное уметь с ним работать. Грешно ругаться на молоток, утверждая, что он плохо забивает гвозди. А поскольку технологии совершенствуются довольно быстро, крайне важно быть открытым для новых идей и способов реализации. Консерватизм в ИТ — это ошибочный путь.

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

Учитесь на чужих ошибках! Такой подход поможет вам сэкономить время, энергию и деньги. Удачи!

Материалы по теме

• 🐛 Типовые ошибки в разработке UI: найти и обезвредить
• 8 самых распространенных ошибок веб-разработчика
• ⚠️ Как не нужно учить TypeScript: 5 распространенных ошибок
• 👶 10 ошибок начинающего разработчика
• ТОП-13 ошибок начинающего программиста

В истории программирования не всегда все было легко и безоблачно. Ведь любому программисту, вне зависимости от опыта и технического бэкграунда, трудно уберечься от ошибок и порой даже небольшого количества плохого кода хватало, чтобы вызвать серьезную проблему. «Библиотека программиста» немного полистала ИТ-летописи и нашла для вас 10 самых худших ошибок в истории кодинга. Поехали!

Ошибка 2000 года

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

Суть проблемы заключалась в том, что большинство устаревших информационных систем, созданных еще в 70-х и 80-х, использовали только две цифры для исчисления года. Это значит, что часы внутри микропроцессоров различного аппаратного ПО регистрировали 1999 год как «99», основываясь на ошибочном предположении разработчиков прошлого, что мы всегда будем жить в 20-м веке и цифра «19» в обозначении года никогда не изменится.

Тогда все полагали, что в 2000 году у всех нас наверняка будут реактивные ранцы, еда в форме таблеток, футуристическая серебристая униформа и человечество к этому времени откажется от старых компьютерных систем середины века. Но чуда не случилось!

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

Терак-25

Плохой код на самом деле может убить. Такая катастрофа произошла с аппаратом лучевой терапии Therac-25, произведенным компанией Atomic Energy of Canada, ставшего причиной гибели не менее шести пациентов. Расследование выявило недоработку системы, вызвавшую передозировку радиацией. Связано это было с трудностью проведения автоматизированных тестов такого специфического программного обеспечения. И поэтому машина, призванная помочь людям, стала машиной для убийств из научной фантастики. Этот случай заставил разработчиков ПО медицинской отрасли крайне ответственно подходить к тестированию такого оборудования.

Сеть AT&T выходит из строя

15 января 1990 года около 50 процентов мобильной сети AT&T вышло из строя. За девять часов простоя более 75 миллионов звонков остались без ответа. И хотя в первоначальных отчетах следствия по этому делу значилось хакерская атака, на самом деле, виновником сего происшествия стало стандартное обновление ПО. Ошибка всего в одной строке кода стоила компании огромных денег. Все организации, целиком зависящие от наличия и качества связи, выставили AT&T иски с внушительными суммами. К примеру, крупнейший авиаперевозчик American Airlines, понес колоссальные финансовые убытки из-за того, что получил наполовину меньше звонков своих клиентов из-за сбоя. Авария 1990 года до сих пор служит прекрасным примером важности тестирования программного обеспечения и служит напоминанием о неразрывной связи между технологиями и экономической деятельностью большинства компаний.

Досрочное освобождение заключенных

В 2005 году в США штате Мичиган произошел сбой тюремной программы, отвечающей за расчет срока наказания заключенных, в результате чего более 20 заключенных досрочно вышли на свободу. Программа ошибочно посчитала смягчающий коэффициент и снизила срок пребывания отбывающих наказание людей в несколько раз. Ошибку в коде заметили не сразу, а лишь по прошествии некоторого времени. И поэтому меру пресечения счастливчикам никто не пересчитывал. Среди них, к слову, не было матерых гангстеров и маньяков. В основном это были мелкие правонарушители, отбывавшие срок за неуплату алиментов, махинации с налогами и незаконное хранение психотропов.

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

Взрыв Ariane 5

Случай произошел 4 июня 1996 года при первом запуске Ariane 5 — одной из самых надежных беспилотных ракетных установок, целью которой было изучение взаимодействия между солнечным ветром и магнитосферой Земли. Через 37 секунд после старта ракета, вылетевшая с космодрома, находящегося на берегах Французской Гвианы, развернулась на 90 градусов и всего через несколько секунд превратилась в огромный огненный шар.

Специальная группа прочесала место происшествия, собирая обломки, чтобы попытаться выяснить, что произошло. Через некоторое время техническая комиссия установила, что авария была вызвана программным сбоем.

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

К слову, целочисленное переполнение является широко распространенной ошибкой в ​​​​компьютерном программировании.

Ошибка Paypal

Что бы вы сделали, если бы PayPal случайно зачислил на ваш счет 92 квадриллиона долларов? Крису Рейнольдсу, 56-летнему американцу, продающему автозапчасти на eBay, не пришлось долго об этом думать. Ведь он даже не успел ощутить себя первым в мире квадриллионером и самым богатым человеком в мире, так как ошибка была устранена в течение нескольких минут. Поэтому, прежде чем мужчина начал мечтать о новом кадиллаке и золотой карте члена королевского яхт-клуба, сумма на его счету вернулась к привычному балансу. Конечно, стоило бы потребовать с компании хотя бы часть этой суммы за моральный ущерб, но, видимо, шок от увиденного не позволил ему сделать это.

Калькулятор Windows

Эта ошибка, существующая в большинстве версий Windows (кроме Windows 10), которую вы сможете проверить самостоятельно.

Для этого нужно:

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

Проблема 2038 года

Ошибка 2038 будет вызвана использованием 32-разрядных процессоров в 32-разрядных системах. Проще говоря, 19 января 2038 года наступит в 03:14:07. Компьютеры, которые все еще используют 32-разрядные системы для управления датой и временем, не смогут справиться с этим изменением. Как и в случае с ошибкой 2000 года, компьютеры не смогут отличить 2038 год от 1970 года.

Однако волноваться не стоит: почти все современные процессоры в настольных ПК имеют 64-битные системы с 64-битным программным обеспечением и в 2038 году само существование 32-битных систем будет под вопросом.

Видео Gangnam Style «сломало» YouTube

Однако корейская поп-группа PSY, выложившая на сервис свой клип с зажигательной песней Gangnam Style благополучно его сломала, превысив допустимую планку.

«Когда мы его делали, никогда не думали, что какое-нибудь видео посмотрят столько раз, но это было до Gangman Style», — написал на своей странице в сети один из разработчиков портала.

Клип PSY опубликовали 15 июля 2012 года и к концу мая 2014 года он стал единственным видеороликом, которой просмотрели больше 2 млрд раз.

BSOD или «Синий экран смерти» — жаргонное название фатальной системной ошибки Windows, показывающей системный сбой, при котором операционка достигала состояния, в котором она больше не могла надежно работать. Как правило, вызывалась она в Windows 95-98 после неожиданного завершения важного процесса или общего сбоя оборудования. Старожилы наверняка помнят этот баг, который довольно часто возникал на заре становления ИТ-культуры.

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

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

• ⚠️ 10 самых распространенных ошибок, ежедневно допускаемых каждым программистом
• ⚠️ Как не нужно учить TypeScript: 5 распространенных ошибок
• 😢 Дорогостоящие ошибки: почему нам пришлось отказаться от Firebase

Что такое баги, ворнинги и исключения в программировании

Разбираемся, какие бывают типы ошибок в программировании и как с ними справляться.

vlada_maestro / shutterstock

Пишет о программировании, в свободное время создаёт игры. Мечтает открыть свою студию и выпускать ламповые RPG.

Многим известно слово баг (англ. bug — жук), которым называют ошибки в программах. Однако баг — это не совсем ошибка, а скорее неожиданный результат работы. Также есть и другие термины: ворнинг, исключение, утечка.

В этой статье мы на примере C++ разберём, что же значат все эти слова и как эти проблемы влияют на эффективность программы.

Словом «ошибка» (англ. error) можно описать любую проблему, но чаще всего под ним подразумевают синтаксическую ошибку — некорректно написанный код, который даже не скомпилируется:

//В конце команды забыли поставить точку с запятой (;)
int =

Компилятор тут же скажет, что в коде ошибка и скорее всего не хватает запятой или точки с запятой.

Также существуют ворнинги (англ. warning — предупреждение). Они не являются ошибками, поэтому программа всё равно будет собрана. Вот пример:

Мы можем попросить компилятор показать нам все предупреждения с помощью флага -Wall:

Предупреждения не являются чем-то критичным, но могут иметь негативные последствия. Например, ваша программа будет использовать больше памяти, чем должна. Так как C++ нужен в том числе и для разработки высоконагруженных систем, этого допускать нельзя.

После восклицательного знака в треугольнике — количество предупреждений

Третий вид ошибок — ошибки сегментации (англ. segmentation fault, сокр. segfault, жарг. сегфолт). Они возникают, если программа пытается записать что-то в ячейку, недоступную для записи. Например:

//Создаём константный массив символов
* s = ;
//Если мы попытаемся перезаписать значение константы, компилятор выдаст ошибку
//Но с помощью указателей мы можем обойти её, поэтому программа успешно скомпилируется
//Однако во время работы она будет выдавать ошибку сегментации
* ( *) s = ;

Вот результат работы такого кода:

Мы выяснили, что баг — это не совсем ошибка, а скорее неожиданное поведение программы или результат такого поведения. Баги могут быть чем-то забавным или неприятным. Например, как в играх:

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

Если ваш код приводит в действие какое-нибудь потенциально опасное устройство, то ценой такой ошибки может быть чья-нибудь жизнь. Такое случилось с кодом для аппарата лучевой терапии Therac-25 — как минимум два человека умерло и ещё больше пострадали из-за превышения дозы радиации.

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

Конвертировать введённое значение не всегда возможно, поэтому функция, которая занимается преобразованием, «выбрасывает» исключение (англ. exception). Это специальное сообщение говорит о том, что что-то идёт не так.

Если разработчик не описывает логику работы программы при вы выбрасывании исключения, то программа аварийно закрывается. Подробнее мы рассказали об этом в статье про ввод и конвертацию в C++.

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

Компилятор C++ при этом может выдать ошибку сегментации, а не сообщение о переполнении стека:

Вот аналогичный код на языке C#:

Однако сообщение в этот раз более конкретное:

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

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

//Пробуем записать в переменную типа int значение, которое превышает лимит
//Константа INT_MAX находится в библиотеке climits
a = INT_MAX + ;

Обратите внимание, что мы получили предупреждение об арифметическом переполнении (англ. integer overflow):

Тем не менее программа скомпилировалась. Если же такая ситуация возникнет во время вычислений, то мы можем не получить предупреждения.

Арифметическое переполнение стало причиной одной из самых дорогих аварий, произошедших из-за ошибки в коде. В 1996 году ракета-носитель «Ариан-5» взорвалась на 40-й секунде полёта — потери оценивают в 360–500 миллионов долларов.

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

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

Второй, более эффективный метод — unit-тесты. Они представляют из себя набор описанных ситуаций для каждого компонента программы с указанием ожидаемого поведения.

Например, у вас есть функция sum (int a, int b), которая возвращает сумму двух чисел. Вы можете написать unit-тесты, чтобы проверять следующие ситуации:

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

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

Запрос «Баг» перенаправляется сюда; см. также другие значения.

Програ́ммная оши́бка (арго баг ) — означает ошибку в программе или в системе, из-за которой программа выдает неожиданное поведение и, как следствие, результат. Большинство программных ошибок возникают из-за ошибок, допущенных разработчиками программы в её исходном коде, либо в её дизайне. Также некоторые ошибки возникают из-за некорректной работы инструментов разработчика, например из-за компилятора, вырабатывающего некорректный код.

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

Программные ошибки локализуются и устраняются в процессе тестирования и отладки программы.

Этимология термина «баг»Править

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

Во время Второй мировой войны словом именовали проблемы с радарной электроникой.

Значение и классификация ошибок программного обеспеченияПравить

В зависимости от этапа разработки ПО, на котором выявляется ошибка, выделяют:

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

• Критические (иногда ) — лишающие программу всей полезности;
• Серьёзные;
• Незначительные;
• Косметические.

По времени появления:

• Постоянно, при каждом запуске;
• Иногда («плавающий» тип);
• Только на машине у клиента (зависит от локальных настроек у клиента).

По месту и направлению:

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

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

Также ошибка может проявляться в виде уязвимости, делающей возможным несанкционированный доступ к системе или DoS-атаку.

Поиск и исправление ошибокПравить

Для отладки программы (англ. ) разработчиками ПО используются специальные программы-отладчики (англ. ). Например, в операционной системе Windows можно использовать программу WinDbg из пакета Microsoft Debugging Tools for Windows. Для GNU/Linux и ряда других UNIX-подобных операционных систем существует отладчик GDB (GNU Debugger).

Отчёты об ошибкахПравить

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

ПоследствияПравить

• Авария ракеты-носителя «Ариан-5» (4 июня 1996) — пример одной из самых дорогостоящих компьютерных ошибок в истории.
• Ошибки в программном обеспечении медицинского ускорителя Therac-25 привели к превышению доз облучения нескольких людей.

• Log Book With Computer Bug . National Museum of American History. Дата обращения: 26 июля 2019. Архивировано 1 июня 2019 года.
• Danis, Sharron Ann: «Rear Admiral Grace Murray Hopper». ei.cs.vt.edu (16 февраля 1997). Дата обращения: 20 января 2015. Архивировано 15 июня 2010 года.
• . Google. Дата обращения: 11 августа 2009. Архивировано 3 февраля 2012 года.
• . Архивировано 3 февраля 2012 года.
• Popper, Nathaniel. Knight Capital Says Trading Glitch Cost It $440 Million (англ.), New York Times (2 August 2012). Архивировано 5 октября 2017 года. Дата обращения: 13 ноября 2017.

СсылкиПравить

• Уязвимости в исходных кодах, «Компьютерная газета». Продолжение: Уязвимости в исходных кодах. Перепечатка: 1 часть (недоступная ссылка), 2 часть (недоступная ссылка).
• 10 худших ошибок в программировании в истории человечества
• 2010 CWE/SANS Top 25 Most Dangerous Software Errors частичный перевод на русский 25 самых опасных ошибок при создании программ
• Ошибки, обнаруженные в Open Source проектах разработчиками PVS-Studio с помощью статического анализа. Можно найти полезные примеры при подготовки статей и презентаций.

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

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

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

В C++ логической ошибкой также называется особое исключение (logic_exception).

Общие причиныПравить

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

Отладка логических ошибокПравить

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

ПримерыПравить

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

• Синтаксическая ошибка (программирование)
• Ошибка на единицу
• Runtime error detection

У этого термина существуют и другие значения, см. Исключение.

Обрабо́тка исключи́тельных ситуа́ций (англ. ) — механизм языков программирования, предназначенный для описания реакции программы на ошибки времени выполнения и другие возможные проблемы (исключения), которые могут возникнуть при выполнении программы и приводят к невозможности (бессмысленности) дальнейшей отработки программой её базового алгоритма. В русском языке также применяется более короткая форма термина: «обработка исключений».

ИсключенияПравить

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

• Целочисленное деление на ноль. Конечного результата у данной операции быть не может, поэтому ни дальнейшие вычисления, ни попытка использования результата деления не приведут к решению задачи.
• Ошибка при попытке считать данные с внешнего устройства. Если данные не удаётся получить, любые дальнейшие запланированные операции с ними бессмысленны.
• Исчерпание доступной памяти. Если в какой-то момент система оказывается не в состоянии выделить достаточный для прикладной программы объём оперативной памяти, программа не сможет работать нормально.
• Появление сигнала аварийного отключения электропитания системы. Прикладную задачу, по всей видимости, решить не удастся, в лучшем случае (при наличии какого-то резерва питания) прикладная программа может позаботиться о сохранении данных.

Виды исключительных ситуаций

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

• Синхронные исключения могут возникнуть только в определённых, заранее известных точках программы. Так, ошибка чтения файла или коммуникационного канала, нехватка памяти — типичные синхронные исключения, так как возникают они только в операции чтения или в операции выделения памяти соответственно.
• Асинхронные исключения могут возникать в любой момент времени и не зависят от того, какую конкретно инструкцию программы выполняет система. Типичные примеры таких исключений: аварийный отказ питания или поступление новых данных.

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

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

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

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

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

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

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

Существует два варианта подключения обработчика исключительных ситуаций к программе: структурная и неструктурная обработка исключений.

Неструктурная обработка исключений

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

Неструктурная обработка — практически единственный вариант для обработки асинхронных исключений, но для синхронных исключений она неудобна: приходится часто вызывать команды установки/снятия обработчиков, всегда остаётся опасность нарушить логику работы программы, пропустив регистрацию или разрегистрацию обработчика.

Структурная обработка исключений требует обязательной поддержки со стороны языка программирования — наличия специальных синтаксических конструкций. Такая конструкция содержит блок контролируемого кода и обработчик (обработчики) исключений. Наиболее общий вид такой конструкции (условный):

Здесь «НачалоБлока» и «КонецБлока» — ключевые слова, которые ограничивают блок контролируемого кода, а «Обработчик» — начало блока обработки соответствующего исключения. Если внутри блока, от начала до первого обработчика, произойдёт исключение, то произойдёт переход на обработчик, написанный для него, после чего весь блок завершится и исполнение будет продолжено со следующей за ним команды. В некоторых языках нет специальных ключевых слов для ограничения блока контролируемого кода, вместо этого обработчик (обработчики) исключений могут быть встроены в некоторые или во все синтаксические конструкции, объединяющие несколько операторов. Так, например, в языке Ада любой составной оператор (begin — end) может содержать обработчик исключений.

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

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

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

Блоки с гарантированным завершением

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

Заключённые между ключевыми словами «НачалоБлока» и «Завершение» операторы (основной код) выполняются последовательно. Если при их выполнении не возникает исключений, то затем выполняются операторы между ключевыми словами «Завершение» и «КонецБлока» (код завершения). Если же при выполнении основного кода возникает исключение (любое), то сразу же выполняется код завершения, после чего весь блок завершается, а возникшее исключение продолжает существовать и распространяться до тех пор, пока его не перехватит какой-либо блок обработки исключений более высокого уровня.

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

Поддержка в различных языкахПравить

Большинство современных языков программирования, такие как Ada, C++, D, Delphi, Objective-C, Java, JavaScript, Eiffel, OCaml, Ruby, Python, Common Lisp, SML, PHP, все языки платформы .NET и др., имеет встроенную поддержку структурной обработки исключений. В этих языках при возникновении исключения, поддерживаемого языком, происходит раскрутка стека вызовов до первого обработчика исключений подходящего типа, и управление передаётся обработчику.

За исключением незначительных различий в синтаксисе существует лишь пара вариантов обработки исключений. В наиболее распространённом из них исключительная ситуация генерируется специальным оператором (throw или raise), а само исключение, с точки зрения программы, представляет собой некоторый объект данных. То есть, генерация исключения состоит из двух этапов: создания объекта-исключения и возбуждения исключительной ситуации с этим объектом в качестве параметра. При этом конструирование такого объекта само по себе выброса исключения не вызывает. В одних языках объектом-исключением может быть объект любого типа данных (в том числе строкой, числом, указателем и так далее), в других — только предопределённого типа-исключения (чаще всего он имеет имя Exception) и, возможно, его производных типов (типов-потомков, если язык поддерживает объектные возможности).

Область действия обработчиков начинается специальным ключевым словом try или просто языковым маркером начала блока (например, begin) и заканчивается перед описанием обработчиков (catch, except, resque). Обработчиков может быть несколько, один за одним, и каждый может указывать тип исключения, который он обрабатывает. Как правило, никакого подбора наиболее подходящего обработчика не производится, и выполняется первый же обработчик, совместимый по типу с исключением. Поэтому порядок следования обработчиков имеет важное значение: если обработчик, совместимый с многими или всеми типами исключений, окажется в тексте прежде специфических обработчиков для конкретных типов, то специфические обработчики не будут использоваться вовсе.

Некоторые языки также допускают специальный блок (else), который выполняется, если ни одного исключения не было сгенерировано в соответствующей области действия. Чаще встречается возможность гарантированного завершения блока кода (finally, ensure). Заметным исключением является Си++, где такой конструкции нет. Вместо неё используется автоматический вызов деструкторов объектов. Вместе с тем существуют нестандартные расширения Си++, поддерживающие и функциональность finally (например в MFC).

В целом обработка исключений может выглядеть следующим образом (в некотором абстрактном языке):

«Строка, считанная из консоли, пустая!»

«Программа выполнилась без исключительных ситуаций»

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