Declined Proposal: A built-in Go error check function, “try”

Not if you're doing it right, which means bubbling up (read: adding the exceptions to the "throws" clause) exceptions that you can't handle _then and there_. You leave the "real" exception handling to the code that's closest to the end user and can actually handle the error in a meaningful way.

For example, in this pattern when you implement the business logic in a REST service, generally there's no catching at all, instead the exceptions are declared as rethrown and way up the stack you would have a global catch all that serializes the errors into JSON and sends them to the user. Simple. In Go you're forced to do "if err{}" checks everywhere, particularly in your endpoint's business logic. It's actually _way less_ verbose and burdensome in Java if you do exceptions the right way.

So you can do (sans syntax):

    ErrorCheckerFunc(fn myParams -> MyFunc(myParams), "message")

    ErrorCheckerFunc(fn myParams2 -> MyFunc2(myParams2), "message2")

and then the actual function:

    ErrorCheckerFunc(fn myFunc, message){
     returnVal, returnError = myFunc();
     switchError:
      case error is foo:
       print error
      case error is bar: 
       log error print "error logged"
      ...
      case n+1 etc

      // you can handle message in a similar way to get 
      // cases by function names, and if you have elixir
      // style quote unquote metaprogramming in Golang you might just be able to get function names based on passed function - I don't think this is in the language spec though it may be possible to do some other way.

      if error not nil do switchError(error)
       return RuhRoh
      else
       return returnVal
    }

Here's the thing, some of us don't want Rust. It looks great! It's perfectly awesome for it's primary domain (i.e. re-implementing critical portions of a modern browser). But it's not what I want to use as my daily driver.

I'm writing stupid shit that's munging CSV files and transforming json documents. I want a language that mostly gets out of my way, but performs well and can scale beyond a couple thousand lines of code. Go fits that space nicely, even with its (or maybe because of) conceptually imperfect error handling.

It wouldn't have been the end of the world but I'm glad to see Go still has alive the spirit that made it so popular in the first place.

    Object thing1;
    try {
        thing1 = doStuff();
    } catch(SameException e) {
        // handle error 1
    }

    try {
        return doOtherStuff(thing1);
    } catch(SameException e) {
        // handle error 2
    }

    thing1, err := doStuff()
    if err != nil {
        // Handle error
    }

    thing2, err := doOtherStuff(thing1)
    if err != nil {
        // Handle error
    }

    return thing2

>People say this, but in practice any code search reveals that "if err != nil { return err }" is everywhere. I believe that many Go projects aspire to annotate all errors, but much fewer actually do.

https://github.com/search?l=Go&q=%22errors.Wrap%22&type=Code

>Ironically, the nice thing about exceptions, as well as Rust error chaining crates, is that they do this automatically, so in practice programs written in languages with those features tend to have better error diagnostics than Go programs do.

Rust is a different ball game. Rust does not try to be simple. It comes at its own costs. (I like Rust too.)

>Computers are better at doing things consistently than humans are.

These empty platitudes come up frequently when debating language decisions online. But, it's so meaningless in so many dimensions. I mean, we could also 'use the computer' by adding C macros on top of Go and use them to reduce repetitiveness, but I don't think many people will applaud you for it. Simply applying computer code to solve a problem does not constitute good design.

Go's proof is in the pudding. It's been extremely reliable for me in real world applications.