[TimJYoung]

"Your whole reply is a straw man. The author is claiming that nothing explodes b/c the error is correctly handled, not b/c it was silently swallowed."

Yes, but I think that this is exactly what pilif is objecting to: the fact that there is no way for the callee to force the caller to deal with the error condition (I'm not sure that this is entirely correct, given that Go has the panic/recover keywords that are later discussed in the article, but then you might as well use exceptions).

IMO, this is very similar to what happens with use-after-free and other types of memory reference errors: they are extremely hard to debug because the symptoms/results of the error can be totally disconnected from the original source of the error, in some cases by minutes or longer. You simply don't want to have a situation where improper state is allowed to linger and further pollute/corrupt any subsequent computations.

[zzzcpan]

And yet forcing the caller to deal with errors still doesn't prevent improper state in any way.

[TimJYoung]

It does if they don't handle the exception, which is the situation being described.

[zzzcpan]

Errors cause side effects, which is how you get to improper state. How does forcing the caller to handle errors helps with removing side effects?

[TimJYoung]

Because the caller either deals with the error (and fixes the state) or they don't, but there's never a case where the callee was unable to force the caller to fix the state. If the caller then goes on to just handle/suppress the exception and continue with the invalid state, then at least they're making an explicit decision that is on them.

[zzzcpan]

That's the point, forcing to handle errors doesn't force to do it properly.

[msbarnett]

It's still strictly better than just letting people not bother to handle them, which is never proper.

[hnbroseph]

"perfect is the enemy of good"