[jerf]

"there's nothing stopping you from ignoring errors and continuing with what could easily be corrupt data."

In theory, this is a big deal.

In practice, it doesn't seem to be a problem. I've neither hit this very often myself, nor have I seen even newbies have much problem with it.

A lot of error handling procedures are based on reacting to C, which was awful. You could call a function, and then have to call another function, deliberately, to see if it failed. This is a nightmare, absolutely. A "Result" type does indeed solve the problem, but the fact that it solves the problem doesn't mean it is the only solution to the problem. The Go solution seems to be about 99.99% effective. It isn't a 100% solution, no, but by 99.9% or 99.99% or so, it takes it below the level of problem that I care about.

The issue with "bubbling" is a bigger problem in practice, certainly.

[brundolf]

> A lot of error handling procedures are based on reacting to C, which was awful

Go's design decisions in general make a lot more sense from this perspective. "X was horrible to deal with in C, how can we make a (reactively) better version?"

The problem is a lot of these choices (willfully?) ignore the decades of language innovation that have happened since C. They are incremental, reactive improvements, where it doesn't feel like the designers necessarily stepped back and looked at the bigger picture

[halkcyon]

> it doesn't feel like the designers necessarily stepped back and looked at the bigger picture

I get the sense that the designers have a huge amount of ego from making C what it is today.

[dosethree]

I've ran into bugs multiple times because I ignored an error result, or overwrote the "err" variable and swallowed an error. Errcheck helps a bit.

Other languages that have exceptions that bubble up the stack have a few advantages (easier to instrument with monitoring, stack traces and line numbers out of the box) but developers often misuse error handling as flow control

[preseinger]

> I've ran into bugs multiple times because I ignored an error result, or overwrote the "err" variable and swallowed an error. Errcheck helps a bit.

Any reasonable code review process would catch these (very obvious) problems.

[dosethree]

my golang code is littered with err handling etc, it’s easy to miss something over the course of dozens of prs. This is something best caught at compile time or by a linter. Or tests which I am often lacking

I find code review unreliable at best for catching bugs or logic errors, but depends on the reviewer

[mcronce]

In practice, it's been a pretty common problem at organizations I've worked in.