Что можно понять из стектрейса?

Что проверяют

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

Как отвечать

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

• тип исключения и сообщение в первой строке, это половина диагноза;
• верхний кадр: класс, метод, файл и строка;
• первый сверху кадр нашего кода, всё выше обычно фреймворк и библиотеки; именно он идёт в отчёт;
• цепочка причин: Caused by в Java, вложенные исключения в других языках. Настоящая причина в самом нижнем звене;
• принадлежность слою: ошибка драйвера базы, таймаут соединения или отказ внешнего сервиса сразу говорят, чей это дефект и кого звать.

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

Где спотыкаются

Прикладывают первую строку или скриншот куска экрана. Без хвоста и без блоков Caused by разработчик видит обёртку, а не исходную ошибку, и первым делом просит полный лог: круг занимает лишний день.

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

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