[otabdeveloper4]

> It's designed to force people to handle the damn error as near to the call as possible.

This is always the wrong way to handle errors.

If a function returns an 'error' that needs be handled at the call site, then it isn't an error, it's a variant return type.

Errors are things that can't be recovered from but must be handled to release resources.

You want this to happen in some central place, not scattered ad-hoc in every place where you use resources; releasing them by hand is worse than manual memory management.

[dgellow]

I think there is a misunderstanding. There isn’t just a single type of errors. Every time you get an error object in Go you ask yourself “should I do something about it or not”. If no then you add some context and return it to the parent, that’s a perfectly valid way to handle it. Otherwise you do your specific piece of logic to recreate your ressources or whatever is needed.

Not all errors require the same treatment and there isn’t a single strategy to manage them.