-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Do not exit if commands return non-ExitCoder errors #595
Conversation
I think this will make the behaviour of many programs uncertain. I'd recommend to add a new method instead of undeprecating an old one + change the existing |
Will this be reaching master soon? Anything I can do to help it a long? |
@gravis I concede that changing the behavior back will confuse some users, but I think there may be a number of users that were (and will be when they upgrade to the latest tag of |
Pinging @meatballhat to get his thoughts |
This is a tough one alright. I think that we're in a bit of a bind. Maybe a silly question, but can we leave master as is and target v2 with the reverted/new behavior? |
@jszwedko @meatballhat the change in #475 was breaking for us in production, the advantage to reverting is that the current state is a removal of functionality which we require where as reverting the change (though a breaking change again) may cause some users to update there applications but at least both paths are available to the developer |
I was also quite confused by the change. The current behaviour is a bug as this is not working as documented. This makes error handling quite inconsistent currently. |
8d021c2
to
2526b57
Compare
@vincentbernat thank you for the nudge, after further reflection on the matter, I agree that it was a regression in behavior that will cause more confusion by being left in than by being reverted. I was trying to reconcile with master and appeared to have closed this PR, but will get it into master now. |
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