proposal: Go 2: block scoped error handling

[mvndaai]

After reading through the problem overview the try() proposal and every comment on the try() issue #32437 I like the idea of try(), thank you everyone for such hard work! The implementations so far have not solved what I view as the issue of error boilerplate, namely the scope of the err var.

Problem

Go scopes errors using inline if statements, but does not scope errors when a variable needs to be used after.

Scoped:

if err := foo(); err != nil {

if _, err := bar(); err != nil {

Not Scoped:

r, err := bar()
if err != nil {

When the error is not scoped it is has multiple problems. The ones that come to mind are:

• Shadowing
• All errs need to be the same type
• The variable existing past when handling makes sense

Proposal

I propose the language add try/handle keywords similar to what was proposed by @james-lawrence.

r := try bar() handle(err error) {
    return err
}

The try keyword would return everything but the final value. The handle block would only run if the final value was non-zero.

This proposal also solves many common complaints from the try proposal #32437:

• Requiring a defer function
• Requiring a named returned which some developers try to avoid
• Implicit error handling
• Obscured return
• Adding complexity to error decoration

Examples

CopyFile

The CopyFile func found in the overview becomes

func CopyFile(src, dst string) error {
	r := try os.Open(src) handle(err error) {
		return err
	}
	defer try r.Close() handle(err error) {
		//handle
	}

	w := try os.Create(dst) handle(err error) {
		return err
	}
	defer try w.Close() handle(err error) {
		//handle
	}

	try io.Copy(w, r); handle(err error) {
		return err
	}
	try  w.Close(); handle(err error) {
		return err
	}
}

The main difference between current error boilerplate and using block scoped error handling are:

• The err from os.Open(src) doesn't live for the whole scope of the function
• The defer functions can handle their errors in the same manner as other functions

Hex

The hex example in the overview becomes:

func main() {
	hex := try ioutil.ReadAll(os.Stdin) handle(err error) {
		log.Fatal(err)
	}

	data := try parseHexdump(string(hex)) handle(err error) {
		log.Fatal(err)
	}

	os.Stdout.Write(data)
}

This is very similar to the current go except the err returned from ioutil.ReadAll isn't overwritten by the err from parseHexdump.

Inline/Curried functions

The try proposal comments included examples of nested/curried functions that caused some worry such as this AsCommit.

func AsCommit() error {
    return try(try(try(tail()).find()).auth())
}

Wrapping a try/handle in () would mean a variable never needs to be saved if it is not wanted. This case is similar to using an anonymous func func()int { ... }() and handling the error, but would allow use of other keywords like break, continue, and return.

Current Go

func AsCommit() error {
	t, err := tail()
	if err != nil {
		return err
	}
	f, err := t.find()
	if err != nil {
		return err
	}
	if _, err := f.auth(); err != nil {
		return err
	}
}

With block scoped error handling (please don't do this)

func AsCommit() error {
	(try tail() handle(err error) {
		return err
	}).(try find() handle(err error) {
		return err
	}).(try auth() handle(err error) {
		return err
	})
}

Struct Init

type foo struct {
	Value int
}

Current go

func styleA(s string) error {
	f := foo{}
	var err error
	f.Value, err = strconv.Atoi(s)
	if err != nil {
		return errors.Wrap(err, "value could not be converted")
	}

func styleB(s string) error {
	n, err := strconv.Atoi(s)
	if err != nil {
		return errors.Wrap(err, "value could not be converted")
	}
	f := foo{
		Value: n,
	}

With block scoped error handling

func styleB(s string) error {
	f := foo{}
	f.Value: try strconv.Atoi(s) handle(err error) {
		return errors.Wrap(err, "value could not be converted")
	}

func styleA(s string) error {
	f := foo{
		Value: (try strconv.Atoi(s) handle(err error) {
			return errors.Wrap(err, "value could not be converted")
		}),
	}

[urandom]

There seems to be a magic variable "err" in the handle block. Where was it defined?

[mvndaai]

@urandom that is on purpose. The proposal says:

handle blocks would have an implicit err variable

Another way to do this would define handle blocks as handle (err error) {}, but I thought since this could be used in nearly every third line it would be nice to be more concise.

If handle blocks define variables it cold probably be overloaded to handle ok functions as well.

Edit: Proposal changed to no longer have an implicit err

[earthboundkid]

I proposed this under the name guard, based on Swift's guard keyword. That might have been in the old issue before try().

guard f, err := os.Open("hello.txt") {
    // err is in scope here
    // block must exit
}
// f is in scope here

Some thoughts:

• I think if something like this is done, it should be called guard because that's a name used by another language.
• Probably it's not enough better than if to be adopted.

[mvndaai]

@carlmjohnson although this looks similar to guard it is different because of the two flow comments you made.

block must exit

The block should not control the flow of your program. Here are some examples why:

Go functions

go try superSlowFunctionThatCanWorkInTheBackground() handle {
    log.Println("logging error because function has already returned", err)
}

Loops

for _, v := range foo() {
    try validate(v) handle {
        log.Println("value in range was invalid", err)
        continue //or break
    }
}

f is in scope here.

If you do not wait for f to be in scope you can do inline defaults.

n := try strconv.Atoi(userInput) handle {
    n = 10
    log.Println("user input could not be converted to a int, using fallback ", n, err)
}

[DeedleFake]

Is try f() handle {} an expression, or is v := try f() handle {} the only legal usage? It looks like an expression from some of the ways that it's used, but is

fmt.Printf(
  "Result: %v\n",
  try strconv.ParseInt(term1, 10, 0) handle { return err } + try strconv.ParseInt(term2, 10, 0) handle { return err }),
)

legal?

I think I prefer this with the explicit variable declaration. It does make it a bit more verbose, but by making it explicit it removes the hidden nature of it and also makes it, as you mentioned, capable of handling other usages such as map retrievals and whatnot.

The biggest issue I have with this is that it puts the actual function call so far down into the line, surrounded by what is essentially boilerplate. It's one of the reasons that I prefer separate ifs for error handling. I find

v, err := strconv.ParseInt(str, 10, 0)
if err != nil {
  // ...
}

to be a lot more readable, and easier to edit later, than

if v, err := strconv.ParseInt(str, 10, 0); err != nil {
  // ...
}

Might just be my personal preference, though.

[mvndaai]

@DeedleFake, yes try f() handle {} is an expression.

I would expect gofmt to put handle blocks on a new line so you can still see the indentations like you would with if err != nil {} and you would need to wrap it in () to make it work inline.

Your function would probably look like

fmt.Printf(
    "Result: %v\n", 
    (try strconv.ParseInt(term1, 10, 0) handle(err error) { 
        return err
    }) + (try strconv.ParseInt(term2, 10, 0) handle(err error) {
        return err
    }),
)

[mvndaai]

@DeedleFake to respond to

I think I prefer this with the explicit variable declaration. It does make it a bit more verbose, but by making it explicit it removes the hidden nature of it and also makes it, as you mentioned, capable of handling other usages such as map retrievals and whatnot.

I haven't put enough thought into the implications, so take this with a bag of salt.

If this isn't implemented until Go2 maybe the return from map retrievals and type assertions should change to return an error rather than an ok bool so new users do not have to understand two flows for handling errors.