That's not really true. It's certainly an idiom in Golang to handle errors individually, but it's not a principle.
The principal is that errors are values like everything else, and you can write code to handle them however you'd like. See, for instance, the "write" example in this post:
>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)
Just to expand on this for other's benefit, it's not idiomatic for errors to result in panics; in general Go code will soldier on. If you're expecting code with trouble to 'throw' an exception and puke, you're in for a bad time, or at least a confusing one.
The principal is that errors are values like everything else, and you can write code to handle them however you'd like. See, for instance, the "write" example in this post:
https://blog.golang.org/errors-are-values
There are libraries that people use (sqlx might be an example) that are more like that example than the if-error-return stuff here.