[coldtea]

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

If they wanted to "force people" they could use Optionals and really force them.

This no more forcing than mandating checked exceptions -- the user can just return the err immediately, like in Java they can just add a throws and propagate for others to handle, or an empty try/catch and ignore it...

[dgellow]

You have go-lint or other linters to enforce it. It’s a per-project choice.

[coldtea]

It's either a "per-project/leave it to the linter" choice, or a "they did this in the language to force people to handle errors close to the source".

Can't have it both ways!

[dgellow]

The “force” is the part that is incorrect, or at least misleading. The go approach is to encourage people to handle it at the call site, and you can use extra tooling to enforce it.

Once you get that point, there is no contradiction.

[Someone]

IMO, Optionals or Either are superior to returning a pair (value, error) because they cannot return both a value and an error, thus removing one possible cause of bugs (likely a fairly small one! As it doesn’t prevent a function from constructing both a result and an error and only returning the error), but I don’t see how optionals force handling errors more than returning a pair (value, error).

Surely, you can just check whether the optional has a value, use it when it is available, and ignore the other case.