FAQ
I used to be all for the explicit error handling, but the kind of code I
have been writing as of late, has changed my mind on that count.

I find myself resorting to the panic/recover mechanic more and more.
Notably for the same reasons put forth by Jens Alfke; By far the largest
use-case of error handling involves propagating the error up the call
chain. Only a top-level function in a package will usually actually do
something with the error. For example: a lexer might be appending source
context information to the error, before passing it on to the outside world.

There is just no point in repeating the `if err != nil { return }` part
over and over again, for no reason at all. It makes the source
unnecessarily difficult to follow and adds zero value.

Fortunately, Go allows us to to have both explicit error handling and
exception semantics at will.

--

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

People

Translate

site design / logo © 2021 Grokbase