Proposal: go2 - Expand check functionality with scoped handle blocks #33002

mathieudevos · 2019-07-09T09:56:09Z

Based on the current proposals and counter proposals I would propose a revision of the check/handle proposal. Proposals can be found here: Go2 Error Handling Feedback

My proposal is to add the option to have fully scoped blocks as well as requiring the handle to scoped, and enforce the variable assignment already used in golang. Finally the handle would move to the bottom, to maintain the logic of top to bottom programming logic (which the original check/handle breaks).

A simple example could be the following:

check {
	foo := FunctionThatReturnsErrorAsLast() // returns var, err
	bar := NoErrorFunction() // returns only value, no error
	AnotherErrorFunction() // returns err
} handle err {
	// you have the error, so you MUST consume it
	return err
}

Alternatively you can also write the following:

foo := check FunctionThatReturnsErrorAsLast() // returns var, err
bar := NoErrorFunction() // returns only value, no error
check AnotherErrorFunction() // returns err
handle _ {
	// err != nil, but no err assignment, as such no consumption
	fmt.Println("Saying hi from the handle")
}

There can be a discussion about omitting the handle part which would automatically translate to the following: handle err { return err; } - however, I prefer to be a bit more explicit and demand that every check has at least one handle assigned to it.

If we take a look at a common used example below:

func CopyFile(src, dst string) error {
	r, err := os.Open(src)
	if err != nil {
		return fmt.Errorf("copy %s %s: %v", src, dst, err)
	}
	defer r.Close()

	w, err := os.Create(dst)
	if err != nil {
		return fmt.Errorf("copy %s %s: %v", src, dst, err)
	}

	if _, err := io.Copy(w, r); err != nil {
		w.Close()
		os.Remove(dst)
		return fmt.Errorf("copy %s %s: %v", src, dst, err)
	}

	if err := w.Close(); err != nil {
		os.Remove(dst)
		return fmt.Errorf("copy %s %s: %v", src, dst, err)
	}
}

This can now be rewritten as such:

func CopyFile(src, dst string) error {
	r := check os.Open(src)
	defer r.Close()

	w := check os.Create(dst)

	check {
		io.Copy(w, r)
		w.Close()
	} handle _ {
		w.Close()
		os.Remove(dst)
	}
	handle err {
		return fmt.Errorf("copy %s %s: %v", src, dst, err)
	}
	return nil
}

or alternatively, depending on your preference:

func CopyFile(src, dst string) error {
	check {
		r := os.Open(src)
		defer r.Close()

		w := os.Create(dst)

		check {
			io.Copy(w, r)
		} handle _ {
			w.Close()
			os.Remove(dst) // (only if a check fails)
		}
		check {
			w.Close()
		} handle _ {
			os.Remove(dst) // (only if a check fails)
		}

		return nil
	} handle err {
		return fmt.Errorf("copy %s %s: %v", src, dst, err)
	}
}

or a mix of oldskool + proposal:

func CopyFile(src, dst string) error {
	r := check os.Open(src)
	defer r.Close()

	w := check os.Create(dst)

	err := io.Copy(w, r)
	if err != nil {
		w.Close()
		os.Remove(dst) // (only if a check fails)
	}
	if err := w.Close(); err != nil {
		os.Remove(dst)
	}
	handle err {
		return fmt.Errorf("copy %s %s: %v", src, dst, err)
	}
	return nil
}

This makes generic error handling (non-lazy as opposed to: if err != nil { return err; }) a lot simpler. Furthermore it's clean for the people reading the code since this is perfectly scoped.

As such the requirements are the following:

Every check must have at least 1 handle below it
check keyword is followed by either {, a function that returns an error as last parameter, or a variable of type error
handle keyword is followed by a variable name, or _ for unused variable name
Checked errors (through the use of check) go STRAIGHT to the next handle block, in order of top to bottom, or "bubble up" in the scope
handle always picks up an error type, it is either straight jumped to by the check as long as it is within its scope or an error can just continue down there.

The goal is to make the codebase repeat itself less while maintaining a clear flow of function handling, while giving the developers the possibility to handle the errors in whichever way they want.

The current try proposal just enables lazy error handling and without other additions to the language it provides a single way to attempt to fix a complex issue, while taking away the developers' choice on how to handle the error(s).

Discuss away, if you vote, please leave a reasoning as to why.

The text was updated successfully, but these errors were encountered:

percybolmer · 2019-07-09T14:54:16Z

This just seems like a mimic of java error handeling with try catch, but just renaming it. I think this has been covered before, not this exact proposal, but try catch.

mathieudevos · 2019-07-09T16:41:38Z

This just seems like a mimic of java error handeling with try catch, but just renaming it. I think this has been covered before, not this exact proposal, but try catch.

It can be seen as such, however it also allows for just adding the check keyword to multiple functions and handling them in a similar way.

Finally, I do prefer the scoping of a try / catch in other languages, as it is clear what is happening.

try proposal only enables lazy error handling, nothing proper to be done (just look at the example of copy)
check is a mess to follow the logic in, going from bottom to top, without the ability to scope it

ianlancetaylor · 2019-07-09T17:45:17Z

When using a check block, what kind of statements are permitted? I didn't see a clear statement of that, though maybe I missed it. In particular it would be unfortunate if adding or removing an error result causes a silent change in behavior at the call site inside a check block, which may be far away.

mathieudevos · 2019-07-09T20:56:55Z

When using a check block, what kind of statements are permitted? I didn't see a clear statement of that, though maybe I missed it. In particular it would be unfortunate if adding or removing an error result causes a silent change in behavior at the call site inside a check block, which may be far away.

The idea would be that a check block would be a scope where all the functions are checked.
If they return as last parameter an error which is not handled (assigned) it would do the check -> handle functionality.

Otherwise all normal operations are allowed, however, to stay consistent with the golang spec, everything declared within the check { ... } block should be scope specific. Newly-declared variables cannot be used outside.

I added more functions in the initial examples (first 2) to showcase how functions would be handled.

ianlancetaylor · 2019-07-09T23:42:24Z

That does suggest that adding an error result to an existing function will cause a silent behavior change. If the check block calls F, and F does not return an error, then the call will occur and nothing else will happen. If we change F to add an error result, then the call will silently change to jump to the handler. While in many cases that will be correct, having a change in one part of a large program cause a silent change in a far away part of the program is problematic.

mathieudevos · 2019-07-10T06:52:52Z

That does suggest that adding an error result to an existing function will cause a silent behavior change. If the check block calls F, and F does not return an error, then the call will occur and nothing else will happen. If we change F to add an error result, then the call will silently change to jump to the handler. While in many cases that will be correct, having a change in one part of a large program cause a silent change in a far away part of the program is problematic.

Would you suggest to require that all functions in a check block send an error at the end?

Alternatively we can suggest that every function inside a check block still requires the check in front of it.
If a person then changes the signature of NoErrorFunction() it will fail to compile as it now returns an error as well.

check {
	foo := check FunctionThatReturnsErrorAsLast() // returns var, err
	bar := NoErrorFunction() // returns only value, no error
	check AnotherErrorFunction() // returns err
} handle err {
	// you have the error, so you MUST consume it
	return err
}

Good catch on the silent behavior.

mvndaai · 2019-07-18T20:36:13Z

My main concern with this is that it disrupts the ability of happy path not being indented. Currently, if you don't use else understanding a function's happy path just means ignoring all indented code.

My other concern is having multiple statements in one check block. Some developers would probably put the entirety of a function within a check block. That would make the code look simpler but changes the philosophy of dealing with errors when they happen, which is my favorite part of go. It makes my code feel safe.

donaldnevermore · 2019-07-20T04:19:36Z

I don't like adding more than one keyword.

ianlancetaylor · 2019-09-17T21:21:06Z

This proposal does not have strong support.

It's concerning that a change in function signature can cause a change in behavior at the call site, possibly skipping other functions in the check block.

When entering the handle block it's not clear which function failed. This doesn't permit handling different function failures differently without a separate check/handle for each function call, which is no better than writing if err != nil.

For these reasons this proposal is a likely decline. Leaving open for one month for further discussion.

ianlancetaylor · 2019-10-15T21:05:29Z

There were no further comments.

gopherbot added this to the Proposal milestone Jul 9, 2019

gopherbot added the Proposal label Jul 9, 2019

ianlancetaylor added v2 A language change or incompatible library change LanguageChange labels Jul 9, 2019

ianlancetaylor mentioned this issue Jul 31, 2019

proposal: Go 2: simplify error handling with try err == nil {} except {} #33387

Closed

ianlancetaylor added the Proposal-FinalCommentPeriod label Sep 17, 2019

griesemer mentioned this issue Sep 17, 2019

proposal: Go 2 review meeting minutes #33892

Open

ianlancetaylor closed this as completed Oct 15, 2019

ianlancetaylor mentioned this issue Oct 29, 2019

proposal: Go 2: aggregate error handling & defer syntax sugar #34403

Closed

bradfitz added the error-handling Language & library change proposals that are about error handling. label Oct 29, 2019

ianlancetaylor mentioned this issue Nov 19, 2019

proposal: Go 2: add try statement to specify handler for unhandled errors #35179

Closed

ianlancetaylor mentioned this issue Aug 18, 2020

Proposal: Go 2: the "watch" statement for easier error handling & more #40821

Closed

golang locked and limited conversation to collaborators Oct 28, 2020

gopherbot added the FrozenDueToAge label Oct 28, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Proposal: go2 - Expand check functionality with scoped handle blocks #33002

Proposal: go2 - Expand check functionality with scoped handle blocks #33002

mathieudevos commented Jul 9, 2019 •

edited

percybolmer commented Jul 9, 2019

mathieudevos commented Jul 9, 2019

ianlancetaylor commented Jul 9, 2019

mathieudevos commented Jul 9, 2019 •

edited

ianlancetaylor commented Jul 9, 2019

mathieudevos commented Jul 10, 2019

mvndaai commented Jul 18, 2019

donaldnevermore commented Jul 20, 2019 •

edited

ianlancetaylor commented Sep 17, 2019

ianlancetaylor commented Oct 15, 2019

Proposal: go2 - Expand check functionality with scoped handle blocks #33002

Proposal: go2 - Expand check functionality with scoped handle blocks #33002

Comments

mathieudevos commented Jul 9, 2019 • edited

percybolmer commented Jul 9, 2019

mathieudevos commented Jul 9, 2019

ianlancetaylor commented Jul 9, 2019

mathieudevos commented Jul 9, 2019 • edited

ianlancetaylor commented Jul 9, 2019

mathieudevos commented Jul 10, 2019

mvndaai commented Jul 18, 2019

donaldnevermore commented Jul 20, 2019 • edited

ianlancetaylor commented Sep 17, 2019

ianlancetaylor commented Oct 15, 2019

mathieudevos commented Jul 9, 2019 •

edited

mathieudevos commented Jul 9, 2019 •

edited

donaldnevermore commented Jul 20, 2019 •

edited