Обработка ошибок в Go | Дмитрий Лукиянчук | Golang Meetup 2022| СберМаркет Tech

[@Freeline95]

Отличное видео, спасибо.

[@evgen_sr]

у меня два вопроса про ошибке 1. пишите ли вы в лог Caller? если да, что будет в логе? самый верхний уровень? или весь stack trace? Не засоряет это логи? да и в проде весь стек выводить странная затея. 2. как я понял из доклада, вы заменяете ошибки, например БД своими, и сразу пробрасываете ее наверх? Например, запрос в БД var( ErrSQL = errors.New("...") ) rows, err := s.db.Query( sqlStatement, ) if err != nil { // что тут возврощать? // так мы получаем точную ошибку sql и понимаем что именно произошло, но привязываемся к реализации (PG одна ошибка, в mysql другая) и не можем проверить через Is без точного понимания типа ошибки return nil, err // или мы возврощаем свою ошибку, но создаем список ошибок, о чем вы говорили, но тут теряем именно само сообщение, что именно произошло, но может отвязаться от реализации, например storage может быть на memory map return nil, storage.ErrSQL // или делаем как в других проектах, например gitea return nil, fmt.Errorf("err: %s", err) }

[@Дмитрий-щ8т3т]

1.а. пишите ли вы в лог Caller? В том приложении, про которое рассказываю - не пишем 1.б. если да, что будет в логе? самый верхний уровень? или весь stack trace? Задача, которую обычно хотят решить выводом caller или всего stack trace - найти точное место, где возникла ошибка и её причины. Этого можно достичь по-разному. - Мы, в основном, достигаем этого тем, что делаем wrap ошибки при каждом пробросе. Тогда по полной ошибке можно понять где она возникла. Пример: ``` err := DBExec(); if err != nil { return fmt.Errorf("DBExec: %w", err) } ``` - Можно добавлять логи где это возможно. Тогда в логе вы захотите выводить файл и строку, там где логгер был вызван. Мы используем под капотом pkg.go.dev/go.uber.org/zap, и он умеет выводить caller из коробки. - Ещё один способ - задавать логгеру namespace в разных слоях кода свой - В zap это pkg.go.dev/go.uber.org/zap#Namespace . - Stacktrace мы выводим только в случае паники - в golang, как вы знаете, паника должна быть исключительной ситуацией. 1. в. Не засоряет это логи? - Чтобы не засорять логи, нужно управлять уровнем логирования - в большинстве логгеров есть уровни FATAL, ERROR, WARNING, INFO, DEBUG. В обычном режиме выставляете уровень INFO+/WARNING+, а DEBUG включать только для диагностики. 1. г. да и в проде весь стек выводить странная затея. - В проде лучше отправлять стек в Sentry с множеством дополнительных полей. sentry.io/ Caller

[@evgen_sr]

@@Дмитрий-щ8т3т спасибо за ответ, после ознакомления с fmt.Errorf("DBExec: %w", err), понял как он работает, что %w это врапер, интересно то, что оно работает только если %w в начале строки или в конце, такое впечатление что идет сравнение строк.

[@Дмитрий-щ8т3т]

2. как я понял из доклада, вы заменяете ошибки, например БД своими, и сразу пробрасываете ее наверх? ... Идея доклада в том, что слой бизнес логики, обращающийся к БД дожен принять решение, как обработать ошибку. Если он не смог с ней справиться - сделать ретрай или выбрать другой способ решения своей задачи, то любой слой выше тем более не сможет. В этом случае слой выше может разве что проигнорировать ошибку или упасть, распечатав ошибку в логи, чтобы вы могли её изучить и починить проблему. Если вопрос в том, как в этом случае сохранить информацию для диагностики, то ответ - лучше всего сделать wrap ошибки (обратите внимание на `%w`): ``` err := DBExec(); if err != nil { return fmt.Errorf("DBExec: %w", err) } ``` Тогда на верхнем уровне вы сможете распечатать всю цепочку через fmt.Print или err.Error(). Также wrapping помогает дотянуться до любой из вложенных ошибок через errors.Is или errors.As - подробнее читайте в go блоге: go.dev/blog/go1.13-errors