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

suggestion: move away from panic in the lib #94

Closed
maleck13 opened this issue May 25, 2018 · 3 comments
Closed

suggestion: move away from panic in the lib #94

maleck13 opened this issue May 25, 2018 · 3 comments
Assignees
Labels
bug Something isn't working

Comments

@maleck13
Copy link
Contributor

Generally I don't think it is good practice to panic in a library. Doing this assumes a number of things about the caller of the library:

  • They have a panic handler
  • OR they want their application to crash if this lib doesn't work

I am not sure we should make these assumptions. In a situation where an error occurs I believe the lib should hand back control to the caller and allow it to decide what to do in that situation as the caller has the full context and domain knowledge.

@jmrodri
Copy link
Contributor

jmrodri commented Jun 26, 2018

$ git grep "panic(" | grep -v test
clients/crd.go:			panic(err.Error())
clients/etcd.go:			panic(err.Error())
clients/kubernetes.go:			panic(err.Error())
clients/kubernetes.go:		panic(err.Error())
clients/openshift.go:			panic(err.Error())
runtime/runtime.go:		panic(err.Error())
runtime/runtime.go:			panic(err.Error())
runtime/runtime.go:		panic(err.Error())
runtime/runtime.go:			panic(fmt.Errorf("Broker is attempting to delete its own namespace"))

@jmrodri jmrodri added the bug Something isn't working label Jun 26, 2018
@jmrodri
Copy link
Contributor

jmrodri commented Jul 10, 2018

IRC meeting this morning the recover docs were referenced:
https://blog.golang.org/defer-panic-and-recover

Particularly these two sections:

Recover is a built-in function that regains control of a panicking goroutine. Recover is only useful inside deferred functions. During normal execution, a call to recover will return nil and have no other effect. If the current goroutine is panicking, a call to recover will capture the value given to panic and resume normal execution.

For a real-world example of panic and recover, see the json package from the Go standard library. It decodes JSON-encoded data with a set of recursive functions. When malformed JSON is encountered, the parser calls panic to unwind the stack to the top-level function call, which recovers from the panic and returns an appropriate error value (see the 'error' and 'unmarshal' methods of the decodeState type in decode.go).

The general consensus is to use a recover paradigm for the panics in the client package. And modify NewRuntime to return errors instead of panicking.

@jmrodri
Copy link
Contributor

jmrodri commented Sep 20, 2020

Closing stale issues

@jmrodri jmrodri closed this as completed Sep 20, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants