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

How to Run without exiting on error? #565

Closed
ebuchman opened this issue Nov 15, 2016 · 4 comments
Closed

How to Run without exiting on error? #565

ebuchman opened this issue Nov 15, 2016 · 4 comments
Labels
kind/bug describes or fixes a bug

Comments

@ebuchman
Copy link

Currently it appears that if a command returns an error, Run will exit the program, since it calls HandleExitCoder, which always exits if the error is not nil. Is it possible to receive that error without exiting? For instance, I've implemented an interactive console that uses this library - the console should not exit just because a command returned an error

@jszwedko
Copy link
Contributor

@ebuchman agreed, we should support this use case. For now you can workaround it by setting cli.OsExiter = func(_ int) {} to avoid exiting on error, but I'll mark this as an enhancement.

@jszwedko jszwedko added the kind/feature describes a code enhancement / feature request label Nov 16, 2016
@wttw
Copy link

wttw commented Dec 17, 2016

Perviously app.Run() would exit only if the command opted in to it by returning an error that implemented ExitCoder. Otherwise it would return that error to the caller for it to handle.

Now HandleExitCoder always exits if err != nil, meaning that app.Run() only ever returns nil.

It looks like an API change (added in f41708) and probably a bug to me, rather than something that needs an enhancement or hack to work around.

@jszwedko
Copy link
Contributor

jszwedko commented Feb 4, 2017

@wttw yeah, I took a deeper dive in and tend to agree with you that the original intent was to only exit if it satisfied ExitCoder (in #361 -- cc/ @meatballhat). It was later adjusted in #496 to satisfy #475, but, in hindsight, the recommendation there should have been to use RunAndExitOnError(). RunAndExitOnError was deprecated when ExitCoder was added, but I could see bringing it back as a convenience function for users who want that behavior, but don't want to wrap their errors in ExitCoders.

Long story short, I agree that this is a bug. We'll need to be careful about releasing this though, since some people may have started to depend on this behavior.

@jszwedko jszwedko added kind/bug describes or fixes a bug and removed kind/feature describes a code enhancement / feature request labels Feb 4, 2017
jszwedko added a commit that referenced this issue Feb 4, 2017
Doing so limits the ability for users to have only some of their errors
cause the application to terminate while allowing others to bubble up.

This was originally an adjustment to #361 in #496 to fix #495, but, in
hindsight, I believe that the better approach is to recommend the use of
`RunAndExitOnError` for this use case (which is undeprecated here).

Fixes #565 #594
@jszwedko
Copy link
Contributor

This is fixed by #595 -- thanks for raising it @ebuchman

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug describes or fixes a bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants