3 ms·
> 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 https://github
by usrbinbash 2y ago
> 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 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 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 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.
- troupo 2y agoThe question of orderly shutdown still remains
- arccy 2y agodeferred functions still run, that's the shutdown.
- usrbinbash 2y agoAs another user has already mentioned, deferred functions run even when a panic unwinds the stack. And semantically, a panic doesn't even need an orderly shutdown. Again: A panic should ONLY be issued if the application enters a state where continuation of normal operation is not possible, and/or may even be ill advised. "Orderly" operations are, by definition, no longer possible at this point.