Verbose and repetitive error handling

In Go, error handling is important. The language’s design and conventions encourage you to explicitly check for errors where they occur (as distinct from the convention in other languages of throwing exceptions and sometimes catching them). In some cases this makes Go code verbose, but fortunately there are some techniques you can use to minimize repetitive error handling.

This is one of the things I can’t stand in C. Every single line requires an if statement to prevent programs from doing crazy things. This is an official, canonical example from the aforementioned link with perhaps “minimal repetitive error handling”:

The correct way to call a function in Go is to wrap it in an if statement. Even Println returns an error value that I’m sure most on the planet will never check. Which brings me to…

Errors passing silently – ticking time bombs to go

To quote Tim Peters:

Errors should never pass silently
Unless explicitly silenced

Go isn’t just stuck with verbose and repetitive error handling. It also makes it easy and tempting to ignore errors. In the following program we would trigger the doomsday device even if we failed protecting the presidential staff.

In theory we could require the programmer never ignore returned errors. By static analysis or convention. In practice it’d be a pain worth enduring only in the most error critical programming tasks. Perhaps that’s Go’s purpose.

panic/recover

Panic and recover aren’t good enough as long as the standard library rarely uses them. Why is an array out of bounds any more cause for panic than a bad format string or a broken connection? Go wanted to avoid exceptions entirely but realizing they can’t – a few exceptions were tacked on here and there, leaving me confused as to which error happens when.

Perhaps another time

So I say this with much regret because Go has a lot of amazing ideas and features, but without modern error handling – I’m not going.

I’m still waiting for that open source, concurrent, bottom left language to come along. Any suggestions are more than welcome.