Comments 10
Бросать паники в go обычно считается антипатерном, и крутить вокруг этого целую библиотеку достаточно спорное решение
Программа может бросать панику если есть баг в коде. Она также может это делать явно, если нарушился инвариант, который по определению не должен был нарушаться. Если из-за бага в коде возникает паника в горутине, то отсутствие recover приведет к немедленному падению всего приложения, а это не всегда хорошо. Поэтому тут есть как минимум два варианта:
Самостоятельно делать обработку паник в горутинах.
Использовать стороннюю библиотеку.
Эта библиотека как раз позволяет решить проблему, причем тут вроде как есть две опции: повторно выкинуть панику либо получить ее как ошибку.
Я конечно не сторонник таких библиотек, так как по сути дела это очень тонкая обертка над стандартными инструментами языка, но не сказать что бесполезная.
Если вы можете продолжить работу, то это не паника, а обычная ошибка. Если есть баг в коде, то его надо править, а не обкладывать костылями. На мой взгляд, recover должен стоять в main и логировать падения, после чего systemd перезапустит программу
Если у вас произошла паника в горутине (не в основной), то отсутствие recover приведет к падению всего приложения. Это не всегда хорошо. К примеру, у вас бекенд с несколькими маршрутами в API (/users/, /posts/ и т.д.), и так вышло, что в каком-то из обработчиков маршрутов (возможно в том, который используется крайне редко) разработчик допустил ошибку и произошел выход за пределы массива/слайса (обратите внимание, что в таком случае приложение скорее всего сможет продолжить работу). В результате, если полениться и не обработать такую панику, то пострадает вся функциональность. Если клиенсткое приложение в случае ошибки будет повторять запрос, то бекенд будет лежать и не подниматься. А еще ситуацию может усугубить например то, что бекенд будет подниматься не моментально, так как, к примеру, ему понадобится инициализировать кеши или еще что-то. В итоге из-за такого бага вы получите большой Downtime, который можно было бы избежать. Я ни в коем случае не выступаю за необходимость использования подобных библиотек (так как это очень тонкая обертка над стандартной библиотекой), но ни в коем случае не стал бы называть это антипаттерном. Особенно вариант обработки паники, с дальнейшим пробрасыванием ее в ожидающую горутину в качестве ошибки (см. WaitAndRecover).
Для этого не нужна какая-то специальная библиотека, в большинстве библиотек для роутинга есть мидлваре, которое перехватывает панику, логирует ее и возвращает 500-ку
Ну если у вас выходы за границу слайдов случаются, то лучше ошибки икать и тесты писать, а не какие-то суррогатные библиотеки использовать для затыкания проблем
Для этого не нужна какая-то специальная библиотека, в большинстве библиотек для роутинга есть мидлваре, которое перехватывает панику, логирует ее и возвращает 500-ку
Если в обработчике хоть где-то используется оператор go, то middleware вас не спасет.
Ну если у вас выходы за границу слайдов случаются, то лучше ошибки икать и тесты писать, а не какие-то суррогатные библиотеки использовать для затыкания проблем
В идеальном мире так и работает. Но речь идет про реальный мир, где люди могут совершать ошибки (и да, когда они выявляются их стараются исправить). Еще бывают баги в хардваре, или совершенно случайно флипнется бит. Да и покрыть тестами программу - дело не простое. К примеру, вы можете прочитать как достигали 100% покрытия бранчей в библиотеке sqlite: https://www.sqlite.org/testing.html
Если вам не хочется читать много текста, то вот этого будет достаточно для понимания:
As of version 3.39.0 (2022-06-25), the SQLite library consists of approximately 151.3 KSLOC of C code. (KSLOC means thousands of "Source Lines Of Code" or, in other words, lines of code excluding blank lines and comments.) By comparison, the project has 608 times as much test code and test scripts - 92038.3 KSLOC.
Ой да.. в C# ошибка в таске не валит основной поток а тут прям надо чтоб завалило все. Баг в коде, а баг в коде или не учтённое поведение? Вы ошибки как обрабатываете? Подымаете на вверх и в лог? Или у вас некий монстр который может обработать все возможные ошибки да еще и с учётом возвращаемых из других сервисов (или сторонних модулей). Скорее всего вы все равно логируете ошибку, что то делаете не зависимо от типа ошибки (ну кроме некоторых предсказуемых) и так же пытаетесь предотвратить падение всего.
Вот благодаря таким библиотекам появляются "сеньёры", которые понятия не имеют о том, как распараллелить обработку массива штатными средствами, как обрабатывать паники, как запускать/останавливать горутины.
Conc: новая библиотека для управления конкурентностью в Go