Как читать ошибки в коде — метод трёх строк вместо паники

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

Разберём на живом примере — вот типичная ошибка Node.js:

TypeError: Cannot read properties of undefined (reading 'map')
    at renderList (/app/src/components/List.js:12:20)
    at App (/app/src/App.js:8:10)
    at renderWithHooks (/app/node_modules/react-dom/...)

1. Найди настоящую ошибку — их может быть несколько

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

Куда смотреть, зависит от языка, и это стоит запомнить один раз: в JavaScript и Node.js суть ошибки — в первой строке блока, дальше идёт хвост вызовов. В Python — наоборот: трейс читается сверху вниз, и суть в самой последней строке. Полистай вывод и найди строку вида Тип: описание — это она.

2. Переведи формулу «Тип: текст» на человеческий

Первая строка всегда устроена одинаково: ТипОшибки: что именно не так. В нашем примере:

• TypeError — операция применена к неподходящему значению.
• Cannot read properties of undefined (reading 'map') — у чего-то, что оказалось undefined, попытались прочитать свойство map.

Перевод: «ты вызвал .map() у переменной, в которой ничего нет». Уже не мистика, а конкретный вопрос: почему там пусто?

3. Найди в стеке СВОЙ файл

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

У нас это List.js:12:20 — файл, строка 12, символ 20. Библиотека почти никогда не виновата; виновато то, что твой код в неё передал.

4. Сходи на строку и предскажи ответ до правки

Открой List.js:12. Там что-то вроде items.map(...). Теперь маленькая привычка, которая прокачивает сильнее всего: сначала сформулируй гипотезу, потом проверяй. «items — undefined. Откуда items приходит? Из пропсов. А кто их передаёт? App. А там данные грузятся из сети — значит, при первом рендере их ещё нет».

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

5. Не видно причину — добавь глаза

Если гипотеза не складывается, поставь перед падающей строкой console.log(items) (в Python — print) и запусти снова. Смотри, что реально лежит в переменной, а не что «должно лежать». Если ошибка живёт на сервере — то же самое покажут логи.

6. Теперь — к ИИ, но с правильным пакетом

Самая частая ошибка новичка — вставить в чат одну строку «TypeError что делать». Модель будет гадать. Собери пакет из трёх частей:

1. Ошибка целиком, вместе со стек-трейсом.
2. Код вокруг падающей строки — функция, где стреляет, плюс место, откуда приходят данные.
3. Что ты делал: «падает при первой загрузке страницы, после обновления работает».

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

Что получится

Та самая красная стена сворачивается в три строки: TypeError → «пусто там, где ждали список» → List.js:12. Диагноз: данные не успели прийти. Лечение: проверка if (!items) return null или значение по умолчанию. Две минуты — и это твои две минуты, а не «ИИ что-то поменял, и вроде заработало».

В каком порядке читать ошибки в Python?

Снизу вверх: последняя строка — суть (ValueError: ...), над ней — цепочка вызовов. Своё место падения ищи в самых нижних строках трейса с твоими файлами.

Почему ошибка указывает на строку, где всё в порядке?

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