Runtime error — ошибка исполнения, отладка stack trace и типы исключений

Runtime error — это ошибка времени выполнения, возникающая после успешной компиляции, когда программа уже запущена. Она отличается от compile-time error (обнаруживается компилятором) и logic error (программа работает, но выдаёт неверный результат). Классические примеры — NullPointerException в Java, Segmentation Fault в C и RuntimeError в Python.

Определение ошибки времени исполнения

Ошибка времени выполнения возникает, когда синтаксически корректный код запускается, но в процессе исполнения нарушает контракт языка или среды. Согласно официальной спецификации Java Language Specification §11, ошибка времени работы (exception) прерывает нормальный поток управления. Компилятор пропускает такой код: проблема не в форме, а в состоянии программы во время выполнения.

Стандарт ISO C11 §5.1.2.3 называет подобные сбои undefined behavior и не гарантирует их обнаружение. C++ Standard §1.9 добавляет термин ill-formed at runtime. В Python Language Reference (docs.python.org) базовый класс RuntimeError описан в главе Built-in Exceptions как маркер аномалии, не относящейся ни к одному другому классу исключений.

Ошибку времени работы вызывают внешние данные, деление на ноль, обращение к нулевому указателю, выход за границы массива, переполнение стека. По данным отчёта Stack Overflow Developer Survey 2024, около 42% разработчиков ежедневно сталкиваются с ошибками времени выполнения — это самая частая причина падения продакшн-систем. Ежегодный State of DevOps Report 2023 фиксирует ту же цифру для инцидентов первой линии.

Сравнение с compile-time и logic error

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

Compile-time. Обнаруживается компилятором до запуска: незакрытая скобка, необъявленная переменная, несовпадение типов. По сравнению с runtime, компайл-тайм проблему исправить проще — компилятор указывает файл и строку. Программа не собирается вообще, и код не попадает в продакшн.

Runtime exception. Проявляется только при исполнении, зависит от данных. В отличие от compile-time, компилятор бессилен: код синтаксически корректен. Пример — деление на ноль, где делитель приходит с ввода пользователя, или обращение к элементу пустого массива.

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

По данным исследования IEEE Software 2021, средняя стоимость починки логической проблемы после релиза в 15 раз выше, чем стоимость исправления ошибки времени выполнения на этапе QA. Именно поэтому статические анализаторы вроде SonarQube и SpotBugs фокусируются на предотвращении рантайм-падений ещё до сборки.

Типы исключений в популярных языках

Каждый язык фиксирует собственный набор runtime-сбоев в стандарте и рантайме.

В Java основные типы описаны в пакете java.lang: NullPointerException (обращение к null), ArrayIndexOutOfBoundsException, ClassCastException, ArithmeticException. По данным Oracle JEP 358 (Java 14), новая система Helpful NullPointerExceptions с 2019 года указывает точное имя null-переменной в stack trace, что сокращает время диагностики в среднем на 40%.

В C и C++ нет структурных исключений — вместо них Segmentation Fault, Bus Error, Stack Overflow. Сбой приходит от операционной системы через сигнал SIGSEGV согласно POSIX.1-2017. C++ добавляет std::runtime_error, std::out_of_range и std::bad_alloc из <stdexcept>. В отличие от Java, где исключение — часть языка, в C это прерывание процесса.

В Python иерархия строится от BaseException. Наиболее частые классы — RuntimeError, ValueError, TypeError, IndexError, KeyError, ZeroDivisionError. JavaScript использует Uncaught TypeError, ReferenceError, RangeError — их описывает спецификация ECMAScript 2024 §6.2. В браузерах эти классы попадают в консоль DevTools вместе с полным stack trace.

Пять шагов отладки runtime-падения

Схема исправления ошибки времени выполнения одинакова для всех языков и не зависит от IDE. Применяйте её последовательно, не перескакивая шаги.

Шаг 1. Прочитайте stack trace целиком. Определите тип исключения, файл и номер строки. В Java trace идёт снизу вверх: причина внизу, первая точка падения сверху. Не пропускайте secondary caused by — там часто скрыта настоящая причина.

Шаг 2. Воспроизведите падение. Зафиксируйте вход, при котором проблема возникает стабильно. Нельзя чинить нестабильно воспроизводимый баг — сначала сделайте его воспроизводимым в 100% случаев на локальной машине.

Шаг 3. Локализуйте место. Поставьте breakpoint или добавьте логирование значений переменных перед точкой падения. Не начинайте править код, пока не увидели состояние программы за миллисекунду до сбоя. В Python используйте pdb, в Java — jdb или IDE-отладчик.

Шаг 4. Исправьте причину. Не глушите симптом через try/catch без анализа — это скроет проблему, а не решит её. Устраните источник: проверьте null, выйдите за границу, добавьте валидацию входа. Комментарий с номером тикета помогает будущим ревьюерам.

Шаг 5. Напишите тест. После фикса добавьте unit-тест с тем самым входом, при котором баг воспроизводился. Иначе через полгода коллега вернёт проблему обратно рефакторингом. Тесты на регрессию — единственная гарантия, что фикс останется.

Что нельзя поймать через try/catch

Существуют ситуации, при которых обработчик исключений не поможет. Нельзя гарантированно поймать OutOfMemoryError в Java: когда куча полна, JVM сама может упасть без вызова catch. Согласно JLS §11.1, Error и его наследники не предназначены для обработки в приложении — это фатальные состояния виртуальной машины.

Нельзя перехватить Segmentation Fault в C стандартными средствами языка. Сигнал приходит от ОС и по умолчанию завершает процесс. Установка handler’а через signal() не гарантирует безопасного продолжения — стандарт C11 §7.14 разрешает undefined behavior после SIGSEGV. В POSIX-системах для этого требуются sigaction и siglongjmp, что редко применяется в приложениях.

Нельзя поймать StackOverflowError без риска повторного переполнения: обработчик исключения тоже требует места на стеке. По этой же причине хвостовая рекурсия в JVM не оптимизируется, а языки без Tail Call Optimization (Java, Python) уязвимы к длинным цепочкам вызовов. Оптимальный подход — переписать рекурсию в цикл.

Мифы об ошибках времени работы

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

Достаточно обернуть весь main в try/catch

Не работает. Глобальный обработчик ловит только те исключения, которые дошли до main. Сбои в фоновых потоках, callbacks и async-задачах проходят мимо. В Java с 2018 года требуется явно передавать UncaughtExceptionHandler через Thread.setDefaultUncaughtExceptionHandler, а в Node.js — слушать process.on(‘uncaughtException’).

Runtime — вина языка

Исключение исполнения — не дефект языка, а следствие входа или состояния. По данным Google SRE Book (O’Reilly, 2016), около 70% продакшн-инцидентов вызваны непредвиденными данными, а не багами компилятора. Смена языка не устраняет причину — переезд с Python на Rust переносит проблему на этап компиляции, но не отменяет её для данных из сети или БД.

Инструменты диагностики: логи, дампы и трейсинг

Помимо stack trace, инженеры используют дополнительные инструменты. Логи уровня ERROR фиксируют контекст падения — обычно ELK Stack или Grafana Loki собирают их с продакшн-нод. Core dump сохраняет полный слепок памяти процесса на момент SIGSEGV — по стандарту POSIX его размер ограничивается ulimit -c и по умолчанию отключён во многих дистрибутивах Linux.

Распределённый трейсинг через OpenTelemetry (стандарт CNCF, стабилен с 2023 года) связывает падение микросервиса с исходным запросом пользователя. По сравнению с одним stack trace, полный трейс показывает цепочку из 10–20 сервисов и быстрее находит корневую причину. Крупные компании — Google, Netflix, Uber — публикуют post-mortem отчёты, где именно трассировка сокращала MTTR (Mean Time To Recovery) в 5–7 раз.

Вопрос-ответ

Что такое ошибка времени выполнения простыми словами? Это сбой программы после успешного запуска. Код прошёл компиляцию, но при работе получил невозможные данные — null вместо объекта, деление на ноль, обращение за границу массива. Программа падает с сообщением exception и завершает процесс.

Чем runtime отличается от compile-time? Ошибка времени компиляции обнаруживается до запуска и не даёт собрать бинарник. Runtime-исключение проявляется только при работе программы и зависит от входа. Первую видит компилятор, вторую — пользователь на проде.

Как найти причину ошибки времени выполнения? Прочитайте stack trace — там указан файл и строка. Далее поставьте breakpoint перед этой строкой и посмотрите значения переменных. В 90% случаев виной оказывается null или неверный индекс, реже — гонка потоков и повреждённый кэш.

Можно ли предотвратить все ошибки времени работы? Нельзя. Даже безупречный код падает при недостатке памяти, обрыве сети, повреждении диска. Задача разработчика — обрабатывать ожидаемые исключения и логировать неожиданные, чтобы получить stack trace для последующего анализа. Наблюдаемость важнее полной защиты.