Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/sync/errgroup: why not recover the fn's err in errgroup #40484

Open
henrycjchen opened this issue Jul 30, 2020 · 6 comments
Open

x/sync/errgroup: why not recover the fn's err in errgroup #40484

henrycjchen opened this issue Jul 30, 2020 · 6 comments

Comments

@henrycjchen
Copy link

@henrycjchen henrycjchen commented Jul 30, 2020

What version of Go are you using (go version)?

$ go version
go version go1.13.6 windows/amd64

Does this issue reproduce with the latest release?

yes

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\henrycjchen\AppData\Local\go-build
set GOENV=C:\Users\henrycjchen\AppData\Roaming\go\env
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\henrycjchen\go
set GOPRIVATE=
set GOPROXY=direct
set GOROOT=c:\go
set GOSUMDB=off
set GOTMPDIR=
set GOTOOLDIR=c:\go\pkg\tool\windows_amd64
set GCCGO=gccgo
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=C:\Users\HENRYC~1\AppData\Local\Temp\go-build068436734=/tmp/go-build -gno-record-gcc-switches

What did you do?

we all know that use goroutine without a recover, the go program may cause a crash

What did you expect to see?

I expect that errgroup can recover the fn's error silently.

What is the reason not to do so? Is recover may decrease the performance of the program?

What did you see instead?

I should add defer func(){recover()}() inside the go func every time I use errgroup

@gopherbot gopherbot added this to the Unreleased milestone Jul 30, 2020
@bcmills
Copy link
Member

@bcmills bcmills commented Jul 30, 2020

CL 134395 does propagate panics to the caller of Wait. It was a bit contentious, but I do plan to dust it off and see if I can push it forward someday.

Loading

@henrycjchen
Copy link
Author

@henrycjchen henrycjchen commented Jul 31, 2020

looking forward to it.

Loading

@ash2k
Copy link

@ash2k ash2k commented Oct 25, 2020

I'd prefer the current behavior - if there is a panic, the program should crash.

Please note that the user can change the current behavior of this library using a tiny wrapper around it that recovers from panics, but if the library changes the behavior it'd be impossible to reverse it. Please let the user choose what their program should do.

Loading

@bcmills
Copy link
Member

@bcmills bcmills commented Oct 26, 2020

@ash2k, it is possible for a library to change the behavior either way.

Consider:

func unrecover(f func()) {
	defer func() {
		if r := recover(); r != nil {
			go panic(r)  // Move the panic to a new goroutine so that it cannot be recovered.
		}
	}()

	f()
}

Loading

@ash2k
Copy link

@ash2k ash2k commented Oct 27, 2020

@bcmills Yes, but unrecover() loses the stacktrace, which is a big deal. https://play.golang.org/p/IVyAExGv6Vu

Loading

@hellodudu
Copy link

@hellodudu hellodudu commented Mar 23, 2021

Perhaps we may make recover as an option when New?

defer func() {
	if g.recover {
		if err := recover(); err != nil {
			stack := string(debug.Stack())
			fmt.Println(stack)
		}
	}

	g.wg.Done()
}()

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants