3 ms·
>You're mostly not supposed to use it or recover from it at run time Are you serious? I thought a key principle of Go was to handle panics in a layered way at
by l33t7332273 3y ago
>You're mostly not supposed to use it or recover from it at run time
Are you serious? I thought a key principle of Go was to handle panics in a layered way at runtime
- maerF0x0 3y agoin my experience that's partly true (it's a judgement call and lies on a spectrum). Like a HTTP server should handle panics in handler code so as to not crash the other go routines handling requests. Or maybe a long running queue worker (eg reading off SQS) should recover from a single go routine handling a message (assuming it can recover and handle the next message successfully). But it'd be way out of scope to put a recover block outside every function call just incase it did a runtime error: index out of range [1] with length . In this way its much different than try catch in languages that explicitly call out what they throw