I want to flag especially that there is not, nor has there ever been, a plan to "push this through".

People consistently say error handling is problematic for them in Go. Overall I think people spend more time writing error checks than they should, and at the same time there are still too many mis-handled errors. We would like to see if we can find a way to make it both less work and more correct. Maybe we can, maybe we can't. The process is slow and needs to backtrack out of formerly-promising dead ends, and that's OK.

There's a very large amount of conversation right now around try, and that's good. Like I said in the tweets, community-wide discussions like this one are open source at its best.

Care to elaborate on both points, or direct me somewhere I can learn more about these opinions? Thanks!

> That would enable library authors to build whatever error handling conveniences they wanted

What I want from a language - especially if it's, like Go, aimed at really big project - is for it to be opinionated and narrowed in options. That's Bill Kennedy's point as well, they're adding a language level feature so now there's one more way to do a very common thing. And when there's multiple ways to do something, they will all get used.

"But what about conventions and code reviews?", you might ask; that's cognitive overload that, if there was only one way, would never be a thing. I mean another feature of Go is that it enforces a certain standard (with tooling and formatters), so that as a development team you should never have to waste time and energy on discussing or arguing about formatting.

I'm not against changing how errors are handled now, as long as they're standardized and the One Way to do things.

This page shows the most common words found in a large corpus of open source Go code on GitHub:

https://anvaka.github.io/common-words/#?lang=go

The top four most common words are "err", "if", "return", "nil". These are each more common than "func" and "string" combined. It's hard to square Pike's comment with that evidence.

I don't know if the try proposal is a good one or not, but I think it's pretty clear that Go's original approach to error handling is quite verbose. Whether it should be that verbose is an interesting question, but personally I think making the user repeat that exact same boilerplate every time adds little value. If you want code that can fail to be visible, at least make the boilerplate shorter, which I guess the "try" proposal accomplishes.

Each of those words are extremely common in Go code, even outside of the 'if err != nil { return err }` construct.

It makes sense they'd be more common than 'func' and 'string' because functions usually contain at least one if statement and return statement, and err is probably the most common variable name, and nil is used to represent the zero value of many different types. The 'string' word is only really used in struct fields, function signatures, and some variable declarations, but usually the string type is inferred on assignment.

Rob Pike is, very likely, using a different set of programs to judge.

Every editor has snippets, or the equivalent, making boilerplate simple to write. And you adapt to reading it pretty quickly - it just becomes punctuation after a while, and you only notice it if it does something unusual.

which is my problem with "try", and why I won't be using it if it gets accepted. It breaks the rhythm of "do something, check for errors, do something, check for errors" that Go code has, and that becomes easy to read.

Edit: grammer and spelling

---

I like writing “if err != nil { … }” so while I disagree with the proposal to add the error check function “try()” I will keep an open mind because I do not have the technical literacy as @griesemer or other people in the Go community to propose something better. I’ll experiment with “try” a few times in personal projects, but I can see myself writing “if err != nil” for several years unless I find a more compelling reason to change, same reason why my team and I haven’t adopted “go mod” despite having Go v1.12.6 (latest stable version as of today) in all our production servers.

[1] https://github.com/golang/proposal/blob/master/design/32437-...

[2] https://github.com/golang/go/issues/32437#issuecomment-49926...

[3] https://github.com/golang/go/issues/32437#issuecomment-50061...

[4] https://github.com/golang/go/issues/32437#issuecomment-50187...

That idiom was my biggest turn off in learning Go.

I would be 100x happier with "if not err {...}"

Personally I don't want error handling changed at all. It's very repetitive in it's current state, but clearer than in any other language I've used.

Most of blame for the mess is that the error interface throws away meaningful information. Then the caller is left mentally checking how to handle the error. Do I value check? Type cast? String check? Does the library expose a function to check, or do I do it myself? Can I get stack traces in some cases without introducing a production cost?

I'm not sure if Go needs a different type of error interface (ie diff methods), or if it needs Generics to solve this properly in my view. But, I just know I've hated the experience.

After I switched to Rust it all felt so familiar, and yet so different. I believe Rust and Go share error patterns. Yet in Rust I'm never left wondering what an error is, what I should do with it, how I check for specific types. This is largely due to awesome enum support and of course generics. Does Go need this feature set to "fix" my complaints with errors? Probably not.. but I do think it needs something.

Though I will agree, I don't think the `if err != nil` is fundamentally the problem with Go's errors, at all. Sure, the UX could be improved, but that's another story all together imo.

The proposal has been partially accepted and implemented in Go 1.13: https://github.com/golang/go/issues/29934#issuecomment-48968...

Edit: spelling, genetics to generics.

Without generics you would have to either throw away the type information, reimplement a `Result` type for every value type, or copy/paste the implementation at each usage site (the common Go pattern).

Go's support for multiple returns itself is also a hack around the lack of support for tuples (which would be trivial to implement if you had generics).

[0]: https://doc.rust-lang.org/std/result/enum.Result.html

I think the important part there - and the contrast with e.g. exceptions - is that an error is treated as normal, as one possible outcome of calling a method, instead of exceptional as exception-based languages seem to be. I mean yeah of course a file can not be available to open, that can be expected. (That is the simple use case of course, I'm sure there's much more complicated situations).

To a first approximation, the purpose of Go is to stop every codebase from reinventing its own tuples or Result<> type.

Go does have generics, the Go compiler could add a chaining syntax for trailing err interfaces (like rust ? / try!) without needing to allow user-defined generic types.

Rust has this too. You can throw away type information and incur a runtime cost just like with Rust by using "Trait Objects", which are Rusts version of interfaces, basically. Luckily most choose not to use this for error communication.

However I struggle to understand that throwing type information away and incurring runtime cost is the pinnacle of error communication.

Furthermore, the idea that this somehow prevents codebases from "reinventing" anything is absolute nonsense. Basically every Go lib out there has different error handling. Hell, I wrote a library of my own (similar to pkg/errors). The very items I listed in my OP showed how every lib has it. You have no idea how each Go lib reinvented the wheel to know how you handle their errors. All with runtime checking. Madness.

The ecosystem exerts a lot of pressure on developers to not reinvent fundamental things, in Haskell I practically never reach for a StrictTuple or StrictEither even when I'd like strictness specifically because they are clunkier and less well integrated with other libraries.

Scala is the only language that comes to mind with this issue (scalaz vs Cats) and my impression is that even they have mostly converged.

I would say Go has much stronger idioms than either of these languages, and wouldn't need to be afraid of people inventing their own fundamental types provided they're included in the standard library.

C/C++ is another example. There are a plethora of string types mostly tied to which base set of libraries you're using. If you're using the C++ stdlib, you have std::string. But if you're using Qt, you're using QByteArray and QString instead. And probably similar for GLib/GTK.

(Does std::string even have any encoding support yet? When I last used it, it was just a string of bytes without any encoding awareness.)

I used golang at an employer and you're right, it's a huge mess (and error handling is just one part of it).

However a few decisions are huge signals that they didn't really think through them. Error handling and the now-solved package management are two big ones.

I keep seeing those claims (e.g. "programming in the large"), but in my experience, practically all the decisions in the language make it more awkward and difficult, even unnecessarily so, to deal with large code bases.

golang's interfaces for instance, are optimized for a small use case, at the expense of them being useless for actually useful things, like tagging and fast code search. The way "methods" are assigned to structs is overly verbose, and makes it easy to have to jump around even several files to figure out all functions that are tied to a struct. The list is too large to list here.

Compared to my Rust code bases, I feel like you need a larger picture of the project to understand what smaller code pieces do.

Is that a good thing though? Not sure, honestly. Should I really feel I understand what a function does, without understanding the functions role on the project itself? How can I truly understand a function without understanding its role?

Go feels like it's easier to understand the implementation, but not the context/purpose. Arguably, this may not be good.

I still prefer Rust, fwiw.

Again, what specifically about golang that makes it that way, other than errors vs. exceptions (keeping in mind that any line in golang can panic)? And what's preventing you from writing similar code in another language? I used Scala before and we had Option and Result types, and treated exceptions as panics. The same applies to Rust.

I found that because of golang's verbosity, it actually made it harder to understand what the entire project was doing. e.g. code bases I worked with were littered with one off functions that amounted to what basically was a map or map+filter, where this would have been a one liner in any modern language, including Java, C#, Kotlin, etc.

Basically, I'm agreeing with the rest of your comment. I find that a "denser" language (to a certain extent) allows you to understand the overall project quicker. There's probably a sweet spot somewhere, and I feel that languages like Java and C# are quite close to it. Keeping in mind that you want a high level overview of a project when you start off anyway, there's no magic solution that will give you that.

It's just that I keep seeing the same claims repeated so many times, and it really seems that they're just being repeated without any basis at all, and repeated just because what the golang author's claimed. So far, almost everything I've seen has been hype.

Also computing is all about eliminating or automating repeaditve tasks. having to write out (almost) the same code after almost every function call goes against the core usefulness of computing.

In go if something is truly exceptional then you can panic, but most of the time an error is non-fatal outside of a particular request (request not just related to a web request).

I agree, many people do errors incorrectly, but `try` does not make them suddenly correct either.

It's quite healthy for the community to have this discussion because this is introducing not just a new built-in function/expressiony thing, but also a means of flow control.

panic() is just another symptom of the same disease.

Exceptions are a very useful tool, and so is pattern matching and support for multiple returns. There is no one true way to handle errors.

No, an uncaught exception crashes the program. I guess you can generically catch all exceptions and get the same affect.

> panic() is just another symptom of the same disease.

Not sure what you mean here

> There is no one true way to handle errors.

Never said there was. I only made a comment that `try` does not fix how people are handling errors.

   func foo() error {
      a, err := bar()
      if err != nil {
         return err
      }

      b, err := baz(a)
      if err != nil {
         return err
      }
     ...
    }

The if nill construct contributes to cognitive load and detracts from code plainly tells you what it does. And speaking from a practical perspective I’m going to be far more productive if 3 lines of commonly used code is turned into five characters.

After a while of working in Go, you get used to the rhythm and you stop noticing the "check for errors" part unless it does something different. You also notice when the check is missing.

And having most of your code devoted to error handling makes total sense. There are usually lots of errors states and only one "golden path" state - properly handling all the possible errors your code could generate will mean writing more error-handling code than logic code because there are more error states than non-error states it can get into.

Instead of "do something, check for errors, do something, check for errors" we would have "do something, check for errors, try something, do something, check for errors" (assuming not all errors are going to be "try"d, and some will need to be wrapped).

It stops being obvious when I've missed an error-check. That's bad.

Either you have used try and therefor there has been a check for errors.

Or you have not used try and therefor you had to assign to err and therefor you have to use a check for errors.

Any assignment to err indicates you need to check for errors just like it is currently.

Controversially I do support generics in go2.

It's probably also biased due to the people who gave up on Go completely because they saw it as a sufficiently major issue and/or had little faith in Go ever improving (I can't exactly put a finger on it, but a lot of the decisions in Go seem to be backed by "... and if you don't like our approach, you're WRONG").

This was also my experience interacting with the Golang team while working at Google.

I don't understand this complain. Ultimately that's how most if not all programming languages are developed. A few individuals act as guide and gatekeepers and that's fine.

Python and Java got this right: everything throws an exception, including out-of-bounds access (IndexError, ArrayIndexOutOfBounds), so by wrapping your whole application in a try/except block you can eliminate a whole class of otherwise fatal errors.

Unless I missed something, the upcoming change isn't going to alter the handling of OOB's, which seems like a missed opportunity because a fully-fledged try/catch mechanism could effectively defuse many bugs.

The "try" proposal is about handling routine, expected errors.

  stream.map(f).collect(…)

   package main
   
   import (
    "fmt"
    "net/http"
   )
   
   func main() {
    http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
     fmt.Fprintf(w, "Hello, you've requested: %s\n", r.URL.Path)
    })
   
    http.ListenAndServe(":80", nil)
   }

   FIRST package main
   AND THEN 
   AND THEN import (
   AND THEN  "fmt"
   AND THEN  "net/http"
   AND THEN )
   AND THEN 
   AND THEN func main() {
   AND THEN  http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
   AND THEN   fmt.Fprintf(w, "Hello, you've requested: %s\n", r.URL.Path)
   AND THEN  })
   AND THEN 
   AND THEN  http.ListenAndServe(":80", nil)
   AND THEN }

So just because the verbose incantation

   if err != nil {
       return err
   }

so it depends on the wording of the question. Basically the real question isn't how big of a pain point it is. It's how much it could be fixed.

my specification for the formatting of the language would be hugely improved by removing the AND THEN line from each line of the code. It's kind of ugly.

Picking on Java, it has checked exceptions, unchecked exceptions, and errors. It's basically a minefield of complexity leading to undefined behavior and/or misbehaving error legs. I can't tell you how many times I've seen InterruptedException mishandled, Throwable (which includes VirtualMachineError) caught with no appropriate handling (quick - what is the appropriate handling of a VirtualMachineError?), or exceptions allowed to wildly propagate.

Wowza, that's a strong stance.

Look, I'm a fan of Go and Java is definitely aged in a lot of places but this is one of the most bizarre claims I've seen. Criticism of Java's exceptions come from both sides, some people who hate unchecked exceptions so "anything can throw" (same reason C++ camp often avoids exceptions); or that checked exceptions are stupid since you can't meaningfully fix Interruptions or IOExceptions so it's verbose and meaningless to force local catches; they almost always need a rethrow. Both of these criticism are fair because in the end they both make sense sometimes and thus are misused for one another occasionally. We'd all like one answer consistently applied but we don't have it here.

Error codes formalized as a part of an API have their place but I find their utility is much more niche than people give them credit for. Why should I decode error codes when a String and a Trace will do? Hint: only when errors have formal semantics such as within a protocol. How I handle the error is partially decided by spec.

But to say that in comparison to Go? Go has its normal err mechanism and panic/recover. err is a huge step up from C style errno/manual checking. In practice, Go's err is embarrassingly used just like a checked exceptions: observe and ignore/log or propagate. You end up just unwinding the stack manually, losing the trace, maybe adding context occasionally, like 70% of the time. You handle it where it's meant to eventually, sure.

Like everybody does, when it is done right.

panic/recover is just unchecked exceptions all over again anyway. They seem to be treated as voodoo idiomatically, sure, but they're there.

Go is a great language that brought some really good language runtime features together in a pretty tidy package. Besides maybe defer, which is pretty clean, error handling just isn't a part of the language that got the polish that other parts of the language got on the first pass.

Error handling in languages with exceptions is (1) more robust, as you actually have to make an effort and explicitly ignore exceptions, and not just accidentally forget to handle them or overwrite them as with golang. (2) you don't have to incur a branch for every error check, which should result in faster code in the non-exceptional case. (3) the code reads easier and clearer, especially where you have to chain calls, which in golang will take up much more code. (4) Exceptions are concrete types, and give you a stack trace automatically, unlike golang where errors are mostly strings and if you need any context you have to manually populate it.

I’d much rather see some kind of genetics support get well integrated, given that’s a problem I run into fairly often.

It seems like a mistake to add a language feature that works against explicit handling. At minimum, the endorsement of returning the raw error reduces clarity on what "good error handling code" should look like.

I'd prefer to see an official errors.Wrap function instead of "try", for the reasons you cite.

(shout out to Dave Cheney's excellent "pkg/errors" implementation of error wrapping)

> If you look closely, error handling is not even in the top 3 challenges faced by developers, it’s number 5

Nonono, that's not what those numbers mean. 5% said it was their absolute biggest problem. For all you know it could be the #2 problem of 90%.

  info := try(try(os.Open(file)).Stat())

[0] https://github.com/golang/proposal/blob/master/design/32437-...

  f := try(os.Open(file))
  info := try(f.Stat())

Meanwhile, the cleanest way to write it right now seems to be:

  f, err := os.Open(file)
  if err == nil {
    return err
  }

  info, err := f.Stat()
  if err == nil {
    return err
  }

If you want to judge code by the worst thing you can do, you'd need to compare with things like:

  var info os.FileInfo
  if f, err := os.Open(file); err != nil {
    info, err = f.Stat()
  }
  if err != nil {
    return err
  }

And you return the error as-is if its nil; seems fine to me?

Your second example is also a bit... far-fetched because it tries to be smart by putting the error checking in the same line. There's also the "line of sight" guideline which states that the happy path should be left-aligned, while edge cases - like errors - should be in indentation [0]. See also the law of least astonishment [1], which your final example does not conform to.

Yes it will compile and yes it is an issue but that's not because of the language. It's because of an attempt at cleverness by writing more compact, of having the happy path in an if, and (arguably) by reusing variable names - but this seems pretty common, and longer variable names like idk, `osOpenError` and `fileStatError` seem to be discouraged in favor of reuse.

So I'm not sure if you're getting your point across like this.

[0] https://medium.com/@matryer/line-of-sight-in-code-186dd7cdea... [1] https://en.wikipedia.org/wiki/Principle_of_least_astonishmen...

Far better to use something more explicit and controllable:

    f, err := os.Open(filename) onerr return 0, err

    f, err := os.Open(filename)
    if err != nil {
        return 0, err
    }

    err := DoSomething() onerr {
        fmt.PrintF("We got error %v\n", err)
        return 0, err
    }

It's clear that there's way too much boilerplate in go procedures that deal with error handling by systematically bailing and passing the failure upstack...

But the most confusing thing to me about try() is that, although it's shaped like a function, it actually returns from the current scope on error. It's dangerous syntactic sugar IMO to make this one function-call-like feature not behave like an actual function call...

So it's legal to write something like...

   panic(panic())

   a := try(try(f()))

The article suggests that try() isn’t solving a big problem. If I were a Go programmer, I think I would want a bigger change, specifically, a proper sum type for errors. In Go, the convention is to return a result and an error despite the fact that essentially every function that can return an error wants to return a result or an error. This results in complexities in the proposal about what the result should be when try() causes an error return. The sensible answer is that there should not be a result.

The way that Rust (and Haskell and many other languages) do so much better than Go has little to do with fancy ? operators. It’s that the return type makes sense.

Of course, sum types without genetics would be odd, but I don’t see how this would stop Go — a special case specifically for “such-and-such type or error” seems consistent with the Go typing philosophy.

  if err != Nil {
    return err;
  } 

Some care still needs to be taken with how other language features interact with it. You'll probably want a sum-type-y way to catch exceptions as an expression eventually. What happens if exceptions are thrown from functions in defers, etc. But unlike more FP languages where error propagation is much easier in a soup of composed functions, Go is much more Java/C#-like. Most functions have much more important names and meaning which make stacktraces much more valuable.