The guidance around this is so vague because, ultimately, error handling
depends on what you want your program to achieve.

For example, if a banking system failed to write a monetary transaction
into some log, perhaps because of a network error, I'd expect there to be
rather thorough logic on how to make sure that everything ends in a valid
state. But what is that state? Should the transaction be written somewhere
else, so it can be resumed later? Should the transaction be aborted
altogether? Perhaps the right answer is a sub-component that triggers a red
lamp in the CEO's office to blink, so that he hurls down into the server
room and start writing apology letters from there.

But that isn't a Go question. It's a question of what the correct behavior
of your program is.

On Saturday, February 6, 2016 at 7:35:37 PM UTC+1, Torsten Bronger wrote:


Coming from Python, I'm used to the mantra "errors should never pass
silently". However, this seems to be a bad idea in Go if you don't
want to end up with something like this:

if _, err := fmt.Printf("Hello!"); err != nil {

I've read much online about best practices in Go error handling, but
no source answered the question which errors to ignore. Is it
correct that there are no publications on this topic and every
Gopher must find a rule set on their own?

It still feels wrong to ignore errors in the first place, though ...


Torsten Bronger Jabber ID: torsten...@jabber.rwth-aachen.de
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 3 of 8 | next ›
Discussion Overview
groupgolang-nuts @
postedFeb 6, '16 at 6:35p
activeFeb 8, '16 at 12:33a



site design / logo © 2022 Grokbase