[swagonomixxx]

I don't think I like any of these proposals. None of them add something that makes me think, "hey, I really need this". Heck, I don't think any of them would even be nice to have.

Go error handling in practice actually works very well. I've been writing Go for a long time and I've never had an issue with it. It's not as fancy as Rust but it works and works well, so if it ain't broke, please don't try fixing it.

[jzoch]

I've heard the same thing about C and why is C++ or Java necessary. Ultimately, I believe programming languages should strive to prevent mistakes early on in the lifecycle of a program. One easy way to do that in production software is to unify the control flow of happy-paths and error-paths (something go already does) and make sure that the error-path is acknowledged and not ignored (something it does not do).

The weakness in the current design is three-fold for me: - I can "forget" to handle in error (ok this can be linted for maybe?) - There is a lot of ceremony in propagating errors up the chain (a very very very common thing to do!) - The convention of (ok, err) is not always conformed to and ultimately provides no benefit over more concrete typings like Result<T, Err>. Now I can easily grep for fallible operations or operations that call fallible operations!

You may be fine with it - I hear the same argument from my coworkers about checked exceptions in java. I think we can do better.

[cy_hauser]

> Go error handling in practice actually works very well.

I disagree. A quick look through the Go code I'm working with now shows more than half the functions that check for and return errors have absolutely no business knowing about the error. These places are in the middle of the call chain, well away from the place that generated or first encountered the error. These functions check the "if err != nil" and bubble them up. That's just noise. Go's error handling in these cases color everything in their path.