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

style guide doesn't follow Style/RescueStandardError #719

Open
Fryguy opened this issue May 29, 2018 · 2 comments
Open

style guide doesn't follow Style/RescueStandardError #719

Fryguy opened this issue May 29, 2018 · 2 comments
Labels

Comments

@Fryguy
Copy link

Fryguy commented May 29, 2018

This issue has 2 parts

  1. Style/RescueStandardError isn't represented at all in the style guide
  2. In particular, https://github.com/bbatsov/ruby-style-guide/tree/2c0b4713794ea07a70ca4e1dee81405350fa7544#no-blind-rescues shows that rescue => e is "good", but this line would fail against Style/RescueStandardError 's default of "explicit".

Since this cop has 2 choices (implicit and explicit), I'm not sure how to make a PR for this change to show that it's "bad" with defaults, but "good" with changes (not even sure the guide cares about those choices)

@tom-lord
Copy link

tom-lord commented Jul 9, 2018

What about just adding a comment to the code:

# good, if Style/RescueStandardError is set to "implicit"
begin
  # a blind rescue rescues from StandardError, not Exception as many
  # programmers assume.
rescue => e
  # exception handling
end

That section of the README was primarily written with regard to rescue Exception, so I think there is certainly some value in highlighting why rescue => e is typically OK - and does not violate the above.

@bbatsov
Copy link
Collaborator

bbatsov commented Jun 12, 2019

Style/RescueStandardError isn't represented at all in the style guide

I guess we'll have to change that and add a rule about it here. :-)

good, if Style/RescueStandardError is set to "implicit"

I've avoided adding any references to specific cops in the guide, as I want it to be focused on the code itself, not on the tools.

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

No branches or pull requests

3 participants