-
Notifications
You must be signed in to change notification settings - Fork 4
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 Errors Should Not Be Rescued #47
Conversation
This may need to be resolved so things don't break. |
|
subject.should_receive(:say).with(command) | ||
Open3.should_receive(:capture3).with(command).and_raise(exception_message) | ||
subject.should_receive(:say).with("Unable to perform '#{command}': #{exception_message}") | ||
subject.perform(command).should be_nil | ||
expect do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
typically we do these on one line.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
also using the return value of a block means using {} instead of do-end according to our style guide.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was past the 120 character mark so i split it up. Which style issue is worse?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll switch to curly and do a line continuation.
👍 |
Command Errors Should Not Be Rescued
A command error should halt further actions, bubble up and return a non-zero from octopolo. If something goes wrong with a command, we likely don't want to continue actions in an unknown state. Also, for using octopolo in scripting it is useful to have a non-zero return code when something went wrong.