The cost of Go's panic and recover

1. go

   1 2,255 127,368 10.0 Go

   The Go programming language

   

   > I also like how golang docs literally describe using panics as poor man's exceptions:

   And I like how https://github.com/golang/go/issues/26799 describes that use of panic in the original version of this bog entry from 2010:

   quote:

   However, this is a poor example and a misuse of panic and recover as exceptions. See https://golang.org/doc/effective_go.html#panic

   The example will be invalid soon with the release of go 1.11 as well. The panic/recover was removed from the unmarshal code. See master's

   end quote.

   The blog entry was later changed because this was fixed. It now refers to marshaling which, sadly, sill uses this mechanism.

   The fact that this is still in the json package is a pain point, yes. Does it validate the use of panic as a form of flow control? No. Here is what "Effective Go" has to say about the topic:

   https://go.dev/doc/effective_go#panic

   quote:

   But what if the error is unrecoverable? Sometimes the program simply cannot continue.

   For this purpose, there is a built-in function panic that in effect creates a run-time error that will stop the program (but see the next section).

   end quote.

2. InfluxDB

   influxdata.com featured

   InfluxDB high-performance time series database. Collect, organize, and act on massive volumes of high-resolution data to power real-time intelligent systems.

   

3. chi

   2 106 19,585 7.5 Go

   lightweight, idiomatic and composable router for building Go HTTP services

   

   The only use for me has been to put a recoverer middleware[1] to catch any unhandled panics and return HTTP 500s in my applications.

   [1] https://github.com/go-chi/chi/blob/master/middleware/recover...

4. kubernetes

   3 783 114,644 10.0 Go

   Production-Grade Container Scheduling and Management

   

   > they are more performant and easier to understand.

   They are more performant because Go decided to make them so. E.g. in Erlang crashing a process is an expected lightweight operation.

   As for "easier to understand"... They are not when:

   - your code is littered with `x, err = ...; if err != nil`

   - it's not easier to understand when the code errors have to be dealt with on a higher/different level. The calling code isn't always the one that needs to deal with all the errors

   Just a very random example (I literally just clicked through random files): https://github.com/kubernetes/kubernetes/blob/master/pkg/con...

   Oh, look, you can't even see the logic behind all the `if err`s which do nothing but return the error to be handled elsewhere.

Suggest a related project