بهتره برنامه گولنگی که مینویسید بتونه از panicهای احتمالای recover کنه خودش رو، چون اگه recover نشه برنامه crash میکنه و باعث میشه کل functionalityهای سرویس (برنامه) بره رو هوا. البته اگه مثلا روی kuber باشید یا با docker-compose باشه یا حتی daemon باشه میتونید restart کنید بصورت خودکار برنامه رو، اما خب اگه اون تیکه از برنامه که داره panic میکنه در hot path باشه خیلی زود مجدد مشکل بوجود میاد.

یه نکته مهمی که در مورد goroutineها وجود داره اینه که اگه شما روی goroutine اصلی (parent) مکانیزم recover در نظر بگیرید تاثیری روی goroutine ساخته شده child نداره و اگه child به هر دلیلی panic کنه ریکاور نمیشه.

خب حالا سوال پیش میاد که ما باید روی هر goroutineی که در برنامه میسازیم یا همون اصطلاحا spawn میشه مکانیزم recover در نظر بگیریم؟
جواب واضحی براش ندارم ولی چند تا نکته دارم که فکر میکنم کمک کنه.
یکی اینکه روی پروسه های long-runningتون حتما panic recover بذارید، مثلا اگه http server دارید معمولا خودشون یه recover middleware دارن فریمورک ها که میشه فعالش کرد.
اگه مثلا یه goroutine دارید که broker consumer هست خوبه که panic recover داشته باشه.
اگه جایی استفاده پیچیده از channelها دارید که confidence ندارید روی فهم communicationشون، چون روی close شدن panic میکنه بهتره recover داشته باشید.

در مورد goroutineهایی که lifetime کوتاهی دارن مثلا قراره یه sms ارسال کنه یا یه http request بزنه لازم نیست تنظیم بشه احتمالا. ولی بهتره یه سری اصول رو کلا رعایت کنید که از panic پرهیز بشه، مثلا تا جایی که میشه و لازم نیست از pointer استفاده نکنید…

این مقاله کوتاه یه تیکه کد آماده کرده که panic رو راحت تر ریکاور کنید در توابع مختلف
Recover panics in all Goroutines you start
https://dev.ribic.ba/recover-panics-goroutines/

نکته آخری هم که دارم اینه که استفاده از panic recover نباید به عنوان یه practice عمومی همه جا استفاده بشه، وجود panic احتمالی نشانه ای برای وجود باگ در پیاده سازی ست که بهتره ریشه موضوع و مشکل پیدا بشه و حل بشه، داشتن ریکاور صرفا برای اینه که تا زمان پیدا کردن مشکل سیستم بصورت reliable کارش رو ادامه بده.

تو تابع panic recover بهتره به اندازه کافی لاگ و متریک خوب بذارید که زودتر مشکل رو پیدا کنید.

@gocasts