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
remove os.Exit from this package #95
Comments
@miekg Agree in principle, could you please propose changes on how this would look? (any api changes - etc) |
either its stop caring all together, or the API must be changed to include an error return parameter and let the client decide. The latter seems the more Go way of doing it, i.e.
will become
And this for all functions in this package. This should be backwards compatible even |
#96 is a very crude PR. I only spend 10 minutes on it; happy to brush it up to standards if something like that is acceptable. |
#96 has been brushed up and should be good to go for a review. |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
/remove-lifecycle stale |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
Stale issues rot after 30d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
Rotten issues close after 30d of inactivity. Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
@fejta-bot: Closing this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/reopen |
@neolit123: Reopened this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
The only places where klog calls Or did I miss something? Let's unfreeze the lifecycle and if no-one brings up any new arguments we can let the bot close this issue if we don't agree to do it manually sooner. /remove-lifecycle |
/remove-lifecycle frozen |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /close not-planned |
@k8s-triage-robot: Closing this issue, marking it as "Not Planned". In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/kind feature
klog inherits calling
os.Exit
from glog when things go sour. This is bad behaviour for a go library. As an application writer I don't want to beholden to klog deciding that my app needs to be killed.Can this be behaviour be removed from this library?
The text was updated successfully, but these errors were encountered: