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

Command.Run should return error #67

Closed
bep opened this issue Mar 14, 2015 · 13 comments
Closed

Command.Run should return error #67

bep opened this issue Mar 14, 2015 · 13 comments

Comments

@bep
Copy link
Collaborator

bep commented Mar 14, 2015

The error handling in general confuses me.

  • There is no obvious way to propagate errors from Command.Run upwards, consider changing signature to return error
  • If Command.Run fails with an error, exit with exit code != 0
@edgard
Copy link
Contributor

edgard commented Mar 19, 2015

👍 this is very welcomed. I cringe everytime I have to do error processing on my inner functions. :D

@bep
Copy link
Collaborator Author

bep commented Mar 19, 2015

Yes, well - I don't see a way to change this without breaking a lot of user code ...

To my surprise, the "other Go CLI framework", seems to be doing exactly the same.

@bep
Copy link
Collaborator Author

bep commented May 31, 2015

A little surprised to see so little interest in this issue.

@eparis what do you to handle this problem? Handle all errors inside the commands?

@eparis
Copy link
Collaborator

eparis commented Jun 2, 2015

For the most part, everything I do called

if err := cmd.Execute(); if err != nil {
   os.Exit(1)
}
os.Exit(0)

And inside run we've got glog.Fatal() (which does os.Exit(1) on unhandl-able errors)

@j16r
Copy link

j16r commented Jul 2, 2015

Perhaps an alternative Run command, e.g:

RunWithError: func(cmd *cobra.Command, args []string) error {

(not the best name to be sure)

@apriendeau
Copy link
Contributor

I would agree with this but it would be a breaking news change. We should always populate the errors up. @eparis a good use case would be testing but also populating the errors up would allow for a single error handling for parent and child commands as well.

@pgruenbacher
Copy link

Agreed, I'm using a fork for the time being. I prefer to have a single os.Exit on a single error exit point.
https://github.com/pgruenbacher/cobra

@eparis
Copy link
Collaborator

eparis commented Aug 30, 2015

So I don't think we can/should change Run. Too many people are using it I'd expect. Maybe we should add a RunE or something like that? Same thing as run but which returns an error which gets populated back up through Execute() ?

@eparis
Copy link
Collaborator

eparis commented Aug 30, 2015

https://gist.github.com/eparis/be6ca4c767e69fcaaea8 ?? Maybe something like that?

@bep
Copy link
Collaborator Author

bep commented Aug 30, 2015

@eparis agree. RunE also matches the naming convention I've seen elsewhere in situation like this.

@apriendeau
Copy link
Contributor

@eparis @bep I agree. That works if we want to use that but I think it would be better in the longer term to make that the default. Possibly a deprecation period?

@apriendeau
Copy link
Contributor

I think that the only thing is that patch would need to have is these: PostRunE, PersistentPostRunE, PreRunE and PersistentPreRunE to achieved the full desired effect.

apriendeau added a commit to apriendeau/cobra that referenced this issue Aug 31, 2015
eparis added a commit that referenced this issue Sep 1, 2015
#67 creates RunE functions to allow for errors to populate to the top
@apriendeau
Copy link
Contributor

@bep @eparis I think this should be good to close with the fix from Alex, right?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants