в месте где она случилась или лучше возвращать на уровень выше. А если этих уровней несколько, то на самый вверх или только на один уровень выше ?
у айтикрасавчика недавно было видео на эту тему, подписан на его канал?
Неа( Если хорошее, то пойду посмотрю
Лучше на самый верх + добавить сообщение в лог.
вот: https://www.youtube.com/watch?v=LwqtG7aAptg, вдогонку рекомендую ещё и это видео посмотреть: https://www.youtube.com/watch?v=eOyxRI8FQm4 косвенно оно касается обработки ошибок в go
Ознакомился с первым видео и сразу вопрос. Делать errors.New и свою ошибку придумать или возвращать err который пришел например от filepath.Abs ?
делать errors.New / fmt.Errorf указывая в ней префикс текущего пакета/метода/функции(кароч идентификатор который поможет понять где именно произошла ошибка) + добавляя в неё ошибку пришедшую из filepath.Abs
Вы где это выкопали?
https://play.golang.org/p/_ARbQV78n1Z ?
да, наверное так
Можно fmt.Errorf("creating file %s: %w", fileName, err)
Да, более подробно получается
Я правильно понял, что делать префикс не канон? Например, есть у меня приложение, которое что-то спрашивает у стороннего апи. Код работающий с апи у меня лежит в отдельном пакете. Делать, для возвращаемых этим пакетом, ошибок префикс в fmt.Errorf не правильно? Почему? Мне кажется это упрощает разбор ошибок, так как впиливать логирование в пакет апи — не самая лучшая идея.
Там что-то другое было. Вообще при оборачивании пишут, что собирались делать или особенности ошибки в текущем контексте. Плюс информация которая поможет понять условия в которых произошло (параметры какие-то)
У меня примерно так: “service1-api: do request error: %w”. Просто в начале указываю, что где именно произошла ошибка, потом контекст, потом оборачиваю. И сразу понятно, где копать.
А почему не лучшая? Лог помогает понять что не так было
Потому что лог помогает понять, что происходит на уровне приложения, а не дополнительного пакета. Представь, что пакет апи генерит кучу ошибок... нужно ли писать это в логи приложения, или в отдельные логи? По моему, лучше вернуть стектрейс этих ошибок на уровень приложения и залогировать нужное там. Можно вспомнить про уровни логирования, поставить трейс везде в пакете апи, но мне это кажется ещё менее идиоматичным.
Но апи кидает подробную ошибку? Тогда да на уровне приложения логирование нужно
Не просто подробную, все ошибки апи врапают низлежащие. Любую из них можно развернуть и залогировать. А дополнительным плюсом, является отказ от зависимости логером для пакета апи.
А вот это текст "service1-api", он каждый раз явно повторяется в коде?
Если лениво сделать свою ошибку так как пакет маленький, повторяется в двух-трёх методах, не страшно. А если пакет разожрался, в корне пакета делаем свою ошибку и в имплементации Error() string указываем префикс
Ну тогда наверное да
То есть внутри например ошибки API может быть ошибка скажем I/O
Ну как I/O. Внутри ошибки API может лежать и ошибка http и io и bytes. Выше развернуть можно и строить от этого логику.
Ну да я просто пример привёл первый, который в голову пришёл
Обсуждают сегодня