Varies widely. Usually you just return the error to let it bubble up to the first caller with enough context to handle it properly. You can also wrap the error message in a string that helps trace the path of the error. If it gets up to main(), you log it and maybe terminate (some errors are fatal, others aren't).
One of the (possibly contentious) principles in Golang is that each error needs to be addressed individually with an appropriate response to the particular case in question.
In practice most Golang errors are handled either:
1) Ignored
2) Logged and swallowed
3) Returned at the point it happened.
4) Fatally exits the program.
One of the "features" of the errors as return codes is that you don't get surprising results that come from the goto style jumps that happen with something like exceptions (unrolling state, etc).
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.
