On: Gopher Wrangling: Effective error handling in Go

[preseinger]

if you write a line of code that can fail, then you should deal with the possibility of that line failing there, directly, in-line

_how_ you deal with that failure is a separate question

but it's critical that every fallible expression explicitly and visibly demonstrates the possibility of failure

this is in no way an "error handling mess" -- on the contrary, it is basically the only way to produce robust and reliable software at scale

[cwalv → preseinger]

In my experience, the vast majority of the time the best (or only) way to correctly deal with the error is to propagate it up the stack. Making this optional (having to explicitly check return values) doesn't make it more likely to be done.

[preseinger → cwalv]

you say "optional", i say "explicit"

it's important that i see the `return` keyword in the source code

[lanstin → preseinger]

i wish people understood this thinking about and handling all errors, as a prime functiom of the code, is why things like Linux and C Python and X server and git and so on are so reliable.

[kaba0 → lanstin]

The only reasons those are reliable is that they have millions of hours of runtime, so that the easier bugs have all been fixed now.

If anything, they have become successful in spite of C.

[lanstin → kaba0]

they are successful in spite of the memory unsafety of C because of the culture that the behavior of a failing system is a principle feature of the code, which is common thinking in C and easier to do when you don't have the crutch of exceptions.