On Monday, 10 October 2022 at 06:21:48 UTC+1 Henry wrote: > You may want to make your app more robust by handling panic in the topmost > layer of your application. With many people working on the code and various > external dependencies, it is often impractical to ensure none of the code > panics. This is where recover comes in.
I'd say that's a very poor reason to use recover. To clarify, there are two types of panic: 1. Those where the code author has invoked panic(...) explicitly (there are various reasons for doing this) 2. Those where the integrity of the runtime has been violated - e.g. a race has caused a data structure corruption. This can be as simple as two goroutines concurrently accessing the same map or slice. In case (2), the entire go runtime is in an indeterminate state. Attempting to recover and continue is futile at best, downright dangerous at worst. Therefore, if you want to handle panics caused by code bugs, you should run your process under an external supervisor (like systemd or kubernetes) which logs the stderr output and restarts the program if it crashes. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/9e2100f3-c1dd-4adc-b536-cfd5c6e71f61n%40googlegroups.com.
