Which rules out the majority of people who learnt to code in the last 25 years (many unis have taught java since 2000ish)

Because people don't ever learn more about programming than what they were taught in university? If this is true, I'm a bit afraid about the career perspectives of these students, and wouldn't really want to be on a team with them...

Only a minority will be sufficiently sadistic to learn C when better alternatives exist. So yes, the above excludes the majority.

An if err with some random one-liner in the err part is not error handling.

You can’t reasonably handle an error condition on a local basis, that’s why exceptions (especially checked ones) are superior. They do the correct thing — either bubble up if it doesn’t make sense to handle them in place, or have them in as broad of a scope as it makes sense with try-catches. Oh and they store the stacktrace, so when an exception does inevitably happen in your software you will actually have a decent shot of fixing it instead of grepping for that generic error message throughout the program (especially if it’s not even written by you!). I swear people lie to themselves with all those if-errs believing they have properly handled an error condition because it took effort.

yes, that's exactly how I also think about Go's error handling. It was always praised the in the early days but it becomes more and more obvious that it's not a good way of handling errors, let alone reading code full of error returns and if err

I see this argument a lot, but error handling is also code that you probably want to read. Especially if you are debugging a problem. My experience is that exposing the error handling logic makes this easier. But I also like John Ousterhout’s suggestion to define errors out of existence where possible (A Philosophy of Software Design). But that requires more thinking than some developers like to deal with.

calling a function that can fail means you need to manage that condition

inspecting the err value returned by a function call is in fact error handling

the point of this design is to keep control flow "on the page"

exceptions do not keep control flow "on the page"

Unfortunately, at scale a feeling of dirtiness doesn't prevent a lot of really bad code from being written. Looking across the Go landscape, inadequate error handling is present in almost all projects I come across.

Is there a language which prevents bad error handling? Many developers praise exceptions but as an Ops person I'm sick of logs full of useless java stack traces which are hard to read and follow (even if you have source code within the reach) and despite verbosity often fail to provide the context necessary to find the failure cause. Best logs I've seen for some reason are all from apps written in C/C++. I know error handling is not only about logs, but in many cases all it does - logging and passing error up the stack.

Rust does it pretty well. No error handling via exceptions, it's all Result<Ok, Err> or Option<Value> types.

This is great since it's enforced on a type-level that every result or option has to be unwrapped before it can be used. Unwrapping is explicit, the code panics if something goes wrong, and the function signature makes it easy to see what sort of errors to expect (especially when using custom error enums for the Err value).

There is one major caveat here, which is that Rust's type system only forces you to check for errors if you plan to use the return value of a function.

An example: You have a function write(), which writes to a file, and which returns Result<(), Err>. (Here `()` is the zero-sized type, ie. an empty tuple).

If you call this function in your code, it might return an error, but you can just silently drop this error. Your linter is going to complain, though. This issue could be fixed with proper linear types (ie. types which must be used once), but adding them to the language would afaik be really difficult at this point.

But other than that Rust is doing pretty well, honestly, and (imo) Go would be a significantly better language if it had a proper Result type, and just used it for all of its error-handling. Sadly, we can't change history.

Unfortunately, as an ops person you are always at the mercy of developers. If a dev writes this code in Go:

    if err != nil {
        return err
    }

If is equally useless as "letting if fly" in Java. However, in Go, developers seem to have more of an awareness for the need for proper error handling, which is not the case with most Java devs. So your problem is cultural, not technical.

I, for one, really like the idea of checked exceptions, forcing you to document and handle your exeptions. However, that idea has turned out to be too tedious for most people, so it didn't catch on.

There's other opinions out there, that discuss the direction taken by Go on error handling, for example this Vlang related article[1] that touched on it (from someone who appears to be a gopher).

However, part of the issue is the tolerance or maturity necessary for being able to handle a different opinion. That someone gives a different preference, for instance Vlang or Odin (that has its own views), can make evangelists or "corporate machinery" upset. Then we can witness mob or anger downvoting. This then limits the debate or creates more of a barrier for different opinions to want to contribute or ever be seen.

[1]: "Is Vlang better than Golang in error handling?" (https://towardsdev.com/is-vlang-better-than-golang-in-error-...).