RL
Да, работает. Я не знал
Size: a a a
2021 June 06
ep
да, убираем go и defer отработает в примере. Я как раз и хотел бы все паники обработать через recovery, но получается это невозможно => я не могу гарантировать что вызвал sync для логов или close для пулла коннектов ?
с
ну так не надо паниковать
VY
ну технически можно просто из любой горутины вызвать что-то типа os.Exit и деферы нигде не сработают
VY
не важно паника или нет
VY
значит, в каждой запущенной горутине где-то должна быть обработка паник
RL
Если я правильно понял, то recover как раз "останавливает" панику из данной горутины
ep
да, я делаю recovery, чтобы написать в лог "сервис остановлен после паники" и дальше продолжаю паниковать, вот так:
defer func() {
if err := recover(); err != nil {
logger.Info("the service has been finished panicking")
panic(err)
} else {
logger.Info("the service has been finished normally")
}
}()RL
А зачем паниковать дальше?
ep
Чтобы паника выдала правильный stacktrace в stderr
ep
ну и плюс там есть еще другие деферы на log.sync, sql.close и т.п.
ep
Получается что после паники скажем в grpc горутинах(которые создаются сами grpc кодом), я могу потерять часть логов
VY
в том же gin есть Recover-мидлварь, которая оборачивает каждый вызов какого-либо обработчика в рекавер
VY
и возвращает 500ку по http
VY
вероятно, тут такой же подход подойдёт
ep
для grpc я решу это общим интерсептором и перехватом паники в нем, просто сложно все это. В каждую свою горутину "на всякий случай" передавать объекты sql, log и т.п. Ибо потенциально каждая горутина может почему-то запаниковать.
VY
так это только в видимости рекавера должен быть sql и log
VY
по-моему не особо сложно - эта проблема везде решена похожим способом
ep
да, вроде есть идея. Отпишусь как реализую.
VY
обычно если запрос изолирован в горутине обработчика запроса, то панику просто в лог выводят, а сервер дальше себе работает