I appreciate this change of heart, as I wouldn't want a half-baked solution to make it into Go, but I hope they don't just stop there.
What the try() proposal gets wrong is that it tries to automatically bounce the error back the stack, being equivalent to "if err != nil { return }", which is ofte reasonable, but at the same time lacks the flexibility that current Go code has in terms of augmenting the error, or indeed handling it: You'd end up with try() calls for some things, but not all, so it's just ironing out one wrinkle and not every wrinkle. The second argument to try() is too heavy-handed. What we need is easy, readable syntax for all cases.
In current Go code, people like the "v, err := someFunc()" syntax because it allows the happy path to stay in the current scope, with the secondary syntax "if v, err :=" introducing a new scope to avoid polluting the parent scope. If you're in the current scope, your code stays flat and clean (although Go's love of shadowing cause subtle).
In my opinion, we need a syntax that is similar to a "catch" block in other languages, but easier. Perhaps something like this:
v := getName() check err: {
return errors.Wrap(err, "could not get name")
}
This allows you to handle the error and augment it, while not introducing anything magical. It's exactly equivalent to an "if v, err :=", but without introducing a new scope
and not polluting the current scope with an error variable. This syntax would happily support fallthrough:
v := getName() check err: {
log.Printf("could not get name, ignoring: %s", err)
}
// v is now the zero value
And of course you could still support a syntax for introducing a new scope:
if v := getName() {
// v is now valid
} check err: {
// You can return or anything else
}
You could easily extend it to error types with some kind of matching syntax:
v := getName() check err == io.EOF {
// On EOF
} check err: {
// All other errors
}
The above syntaxes don't support chaining. I'm on the fence. I like Rust's "?" postfix syntax, and I think it could work:
// This could be "monadic"; the first error short-circuits
ceo := getPerson()?.getCompany()?.getCEO() check err: {
return errors.Wrap(err, "couldn't get CEO")
}
But why not just let "." be smart about errors and fall through like this?
ceo := getPerson().getCompany().getCEO() check err: {
return errors.Wrap(err, "couldn't get CEO")
}
After all, "." can know if the function returns multiple values, and "." on a tuple (or whatever Go calls it) isn't valid, so why not "promote" the "." to a high-level operator here?
The awkwardness of the try proposal goes deeper than just error handling, too, I think. One reason Go can't solve its error handling problem elegantly is because of its reliance of multiple, exclusive return types. Almost all functions with this signature:
func getName() (string, error)
...obey the unwritten rule that the function returns
either a valid value, or an error. If you get an error, the value is supposed to be unusable, and the way to check for it is to look at whether there was an error.†
In many type systems, a situation where a return value can be either A or B is variously called a union, or discriminated union, or enum, or sum type, which is the term I prefer. It's always bugged me that Go's designers didn't go one step further and made sum types a first-class citizen, because I think it would fit Go rather nicely. TypeScript solves it this way:
function getName(): string | number
And you can also define types this way:
type number = int | float64
This, incidentally, introduces the idea of optional values:
function takesOptional(x: string | null)
Back to error handling, it would be more natural for a function to declare itself this way:
func getName() string | error
After all, it returns a value
or an error. It can never be the superposition of both.
In this regime, anything that gets a value needs to explicitly check for what it is. "switch" on type would work, just like today, but that gets verbose for mere errors. So we just say that the "check" syntax as outlined above would work for any union that involves an error. In other words:
func getThing() Person | Company | error {
...
}
thing := getThing() check err: {
return errors.Wrap(err, "can't get thing")
}
We can do this because we can say that "error" is special and known to the compiler, just like make() etc. are special.
Of course, sum types go beyond errors, and open other avenues that are very poorly served by Go right now.
---
† This, unfortunately, isn't universally true. For example, io.Reader's Write() method's contract says that if it returns io.EOF, it may still have read a final amount of data into its buffer. Many get this wrong and ignore the data read. Which points to the problem of conventions that only seem like unwritten rules, but also highlights how the lack of strong type-system support creates the issue in the first place.