Comments 3
Привет из будущего где golang conf будет 4 июня !)
Тут слишком много букв, поэтому ничего не понятно (и много неправильно)
Как должно быть:
а) для библиотек:
ошибки не выводить в лог, т.к. у всех логгеры разные
делать "Текстовый wrapping %w" ошибок
все ошибки возвращать
не делать панику (или fatal)
б) для остальных приложений:
все ошибки выводить в лог сразу же в месте появления ошибки, даже если ошибку возвращаем наверх.
при возвращении ошибки наверх - надо ошибку вывести в лог ещё раз, второй раз с новым "Текстовый wrapping %w" ошибок
делать "Текстовый wrapping %w" ошибок
ошибки старться обработать на месте, возвращать как можно меньше ошибок
при старте приложения при ошибке сразу делать панику, после старта паники стараться не делать.
Статья получилось длинной соглашусь, спасибо что прочитали ее всю.
В статье я не говорю как должно быть, а показываю когда и в каких условиях нужно использовать тот или иной подход.
Дополнения к вашему варианту "Как должно быть:"
а) для библиотек:
ошибки не выводить в лог, т.к. у всех логгеры разные
Верно, в статье также говорится, но есть slog и стандартный пакет log, которые при определенных условиях можно применять. Примеры: net/http, gin
делать "Текстовый wrapping %w" ошибок
Верно, в статье также говорится, плюс я говори еще про Custom Errors, который широко используется. os.PathError
все ошибки возвращать
Верно, в статье также говорится, но есть исключения описанные в статье. Примеры из stdlib найдены через поиск _ = : math, strconv.
не делать панику (или fatal)
Верно, но есть исключения описанные в статье. Примеры из stdlib: strings, strconv.
Зачему, что исключения я описывал в статье и в самих регламентах они помечены "?" - применять при определенных условиях.
б) для остальных приложений:
все ошибки выводить в лог сразу же в месте появления ошибки, даже если ошибку возвращаем наверх.
Логирование по месту захламляет лог дублями и усложняет понимания реального количества ошибок, поэтому не могу советовать этого.
при возвращении ошибки наверх - надо ошибку вывести в лог ещё раз, второй раз с новым "Текстовый wrapping %w" ошибок
Такая же проблема, как описанная к пункту выше.
делать "Текстовый wrapping %w" ошибок
Так и есть в статье, плюс Custom Errors. stacktrace и backtrace я поставил как практики под "?, но для получения быстрого результата в легаси проектах этот подход приемлем.
ошибки старться обработать на месте, возвращать как можно меньше ошибок
Опишите примеры таких ошибок. В сервисах я встречал ошибки с валидацией данных, некорректность работой внешних ресурсов (БД, микросервис, шина данных) и это все тяжело пропустить. Но удобно обработать централизовано показывая ошибку, но скрывая чувствительную информацию от пользователю.
при старте приложения при ошибке сразу делать панику, после старта паники стараться не делать.
Про паники так и указано в статье.
Регламент для работы с ошибками в Go