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

No panics #51

Closed
HelloGrayson opened this issue May 17, 2017 · 5 comments
Closed

No panics #51

HelloGrayson opened this issue May 17, 2017 · 5 comments
Assignees

Comments

@HelloGrayson
Copy link
Contributor

Dig should always return errs so that FX can control what those errs mean.

@glibsm
Copy link
Collaborator

glibsm commented May 17, 2017

dig doesn't panic?

$ ag panic
container.go
138:                            err = fmt.Errorf("panic during Resolve %v", r)

container_test.go
520:func TestPanicConstructor(t *testing.T) {
526:            panic("RUH ROH")
533:    require.Contains(t, err.Error(), "panic during Resolve")

examples/three/three.go
60:             panic(err)
67:             panic(err)

@glibsm
Copy link
Collaborator

glibsm commented May 17, 2017

We actually panic recover and return an error if something blows up in a constructor as well:

defer func() {
	if r := recover(); r != nil {
		err = fmt.Errorf("panic during Resolve %v", r)
	}
}()

@glibsm
Copy link
Collaborator

glibsm commented May 17, 2017

we could even add the same panic recovery system to Invoke as well

@HelloGrayson
Copy link
Contributor Author

Ok - so we never panic, that's great.

I'm actually not sure if we should recover other panics TBH, but that's a separate concern.

@glibsm
Copy link
Collaborator

glibsm commented May 19, 2017

I'm actually not sure if we should recover other panics

The initial idea was to add them to cover reflect specific errors - it tend to panic a lot.

But now that I think about it, we're also going to catch panics in constructors -- and we will return an error. And you're right, that might not be desired. Lets talk about it in another thread to see if we should drop that

hbdf pushed a commit to hbdf/dig that referenced this issue Jul 14, 2022
* Ignore mem and cpu files
* Add check for off-master baselines. Allow to override
* Colors. Colors everywhere
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants