Practical use cases of recover in golang

119 views
Skip to first unread message

cg-guy

unread,
Oct 9, 2022, 5:16:52 PM10/9/22
to golang-nuts
Hi Team,

Whatever I have been worked so far with golang,I did not use recover() function . 
Curious to know if anyone using recover in production code and can you please 
the scenarios where it is used. 

Thanks

Ian Lance Taylor

unread,
Oct 9, 2022, 8:14:18 PM10/9/22
to cg-guy, golang-nuts
You may want to look at how it is used in the Go standard library, for
example in the encoding/json package.

Ian

Eswaran S.K.

unread,
Oct 9, 2022, 10:53:40 PM10/9/22
to golang-nuts
Production Code is typically written with multiple layers of abstraction.
Typical patterns involve generic ones like Proxy / Command patterns.

In these types of pattern, execution context is provided by the Client/Invoker.
But, the implementation for execution is done by the different abstraction object.

Also, in such cases typically there are multiple implementation objects that gets executed based on configuration/scenarios that are only decided at runtime.

Based on organizational structure and how work gets divided it might be built by different teams within or spanning multiple organizations.

In such chases, to gracefully handle and implement the functionality of the Client/Invoker, recovering from panic's is important.
I have personally used recover() to gracefully handle scenarios that arose from third party libraries.

Kurtis Rader

unread,
Oct 9, 2022, 11:20:31 PM10/9/22
to cg-guy, golang-nuts
The Elvish shell uses panic capture to ensure an interactive Elvish shell that paniced is replaced by a recovery shell. While still outputting important information about the panic. See this code. In other words, sometimes you want to ensure that a) information about the panic is captured (such as logging the panic via an external service) and b) doing something other than simply terminating. Whether to capture a panic is obviously dependent on the specific situation.

I'll also note that I'm working on a change to the Elvish project that will capture a panic to solve the problem of the builtin "exit" command not triggering deferred behaviors; such as capturing profiling data. See this issue. So that is another, highly context dependent, case where capturing a panic is useful. I've got to say that Go's panic/recover mechanism is a beautiful design.

On Sun, Oct 9, 2022 at 2:17 PM cg-guy <mohame...@gmail.com> wrote:
--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/00f1a25f-2f95-4ed7-8acd-6510bae85c30n%40googlegroups.com.


--
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

Henry

unread,
Oct 10, 2022, 1:21:48 AM10/10/22
to golang-nuts
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.

Brian Candler

unread,
Oct 10, 2022, 3:22:26 AM10/10/22
to golang-nuts
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.

Vladimir Varankin

unread,
Oct 10, 2022, 6:01:30 AM10/10/22
to golang-nuts
One particular example is if you use std's net/http server, you (indirectly) use recover. The std's documentation for the Handler interface has a section, where they outline how the server recovers from a panic, that fired in the context of a request https://pkg.go.dev/net/http#Handler
Reply all
Reply to author
Forward
0 new messages