Значит вы как программист ошибку должным образом не обработали судя по всему (Кстати большинство этим и грешат. Отсюда ненависть к if err!=nil при переходе на Go)?
логичный вывод Обработал должным образом, врапнув ее при помощи xerrors, который добавляет информацию о точке вызова
теперь еще понемногу появляются switch по errorrs.Is/As
Честно говоря, я не хочу с вами спорить, не люблю идиотов и софистику
И потом влупляешь в этот трейс, видишь, откуда был вызов, но абсолютно не влупляешь причину, потому что "контексто зависимых данных" которые привели к ошибке не собрал?
контексто-зависимые данные есть в форматированном сообщении
Это если ты как программист их туда прикрепил в нужном месте. А не написал обобщенный обработчик всех ошибок на все приложение. А если прикрепил в нужном месте, стэк трейс может быть и не нужен, потому что и без него все понятно. Вернулись по кругу.
> А не написал обобщенный обработчик всех ошибок на все приложение. А кто так делает в Go? > А если прикрепил в нужном месте, стэк трейс может быть и не нужен может быть Вызовы это динамическая вещь, они происходят во время исполнения программы, на этапе компиляции вы не знаете чем и когда будет вызвана функция есть такие неприятные вещи как рекурсия и интерфейсы
> А кто так делает в Go? Вы не поверите, регулярно натыкаюсь на такое. Везде if err !- nil return err пробрасываемый наверх и универсальный обработчик. Причем со стек трейсом 😂 Который не раскрывает ничего, потому что генерируется не так где ошибка произошла, а там где она была обработана.
Ну так никто не мешает писать return xerrorf("foo: %w", err), и тогда трейс будет нормальный.
Я говорю про тот трейс, который возникает при оборачивании ошибки и сохраняет путь от её возникновения до обработки, это очень полезно.
Обсуждают сегодня