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

runtime: can't recover #50512

Closed
letian0805 opened this issue Jan 8, 2022 · 4 comments
Closed

runtime: can't recover #50512

letian0805 opened this issue Jan 8, 2022 · 4 comments

Comments

@letian0805
Copy link

@letian0805 letian0805 commented Jan 8, 2022

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

$ go version

Does this issue reproduce with the latest release?

version go1.16

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

go env Output
$ go env

What did you do?

package main

import (
    "fmt"
)

func main(){
    defer func() {
        test()
    }() 
    //defer test()  //if add this line, it will work
    panic("test")
}

func test() {
    if err := recover(); err != nil {
        fmt.Println(err)
    }   
}

What did you expect to see?

recovered

What did you see instead?

panic: test

goroutine 1 [running]:
main.main()
/home/letian/work/go/src/test/test.go:11 +0x5b
exit status 2

@seankhliao
Copy link
Contributor

@seankhliao seankhliao commented Jan 8, 2022

https://pkg.go.dev/builtin#recover

Executing a call to recover inside a deferred function (but not any function called by it) stops the panicking sequence by restoring normal execution and retrieves the error value passed to the call of panic.

Closing as working as intended

@letian0805
Copy link
Author

@letian0805 letian0805 commented Jan 8, 2022

@seankhliao I know how to use recover. Maybe I didn't express it very clearly. In fact, I'm more wondering why it's designed this way. Since the defer function will be executed no matter what, why must it be designed to require recovery in the top-level function of defer to recover from panic? Sometimes this design makes it look more like a bug.

@seankhliao
Copy link
Contributor

@seankhliao seankhliao commented Jan 8, 2022

see the discussion in #34530

@letian0805
Copy link
Author

@letian0805 letian0805 commented Jan 8, 2022

@seankhliao Thanks!

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

No branches or pull requests

2 participants