Fix some rescue calls that do not specifiy error type.#6310
Fix some rescue calls that do not specifiy error type.#6310bundlerbot merged 2 commits intorubygems:masterfrom
Conversation
|
Thanks for opening a pull request and helping make Bundler better! Someone from the Bundler team will take a look at your pull request shortly and leave any feedback. Please make sure that your pull request has tests for any changes or added functionality. We use Travis CI to test and make sure your change works functionally and uses acceptable conventions, you can review the current progress of Travis CI in the PR status window below. If you have any questions or concerns that you wish to ask, feel free to leave a comment in this PR or join our #bundler channel on Slack. For more information about contributing to the Bundler project feel free to review our CONTRIBUTING guide |
utilum
force-pushed
the
rescue_unspecified_exception
branch
from
c9a5b4f to
907689d
Compare
|
Hi, can you please fill out the PR template. |
segiddins
left a comment
segiddins
left a comment
There was a problem hiding this comment.
How did you decide between Runtime and Standard error?
lib/bundler/cli.rb
Outdated
|
|
||
| Bundler.ui.warn "The latest bundler is #{latest}, but you are currently running #{current}.\n#{suggestion}" | ||
| rescue | ||
| rescue RuntimeArgument |
There was a problem hiding this comment.
What is “RuntimeArgument”?
There was a problem hiding this comment.
Naught but a tyop. Fixed.
utilum
force-pushed
the
rescue_unspecified_exception
branch
from
907689d to
2b8a80c
Compare
I preferred |
|
This looks good to me once the tests are green. 👍 |
|
ping @utilum |
|
Sorry for the delay. |
|
Anyone? |
segiddins
force-pushed
the
rescue_unspecified_exception
branch
from
2b8a80c to
c18c48d
Compare
|
@bundlerbot r+ |
|
📌 Commit c18c48d has been approved by |
Fix some rescue calls that do not specifiy error type. ### What was the end-user problem that led to this PR? The problem I noticed was in style, several instances of `rescue` clauses that do not specify an exception type. This is noted in in the Ruby Style Guide as [Avoid rescuing the Exception class](https://github.com/bbatsov/ruby-style-guide#no-blind-rescues). ### What was your diagnosis of the problem? My diagnosis was that at least some of those are leftover style. They are noted in `.rubocop_todo.yml`. To make sure, I asked on Slack. ### What is your fix for the problem, implemented in this PR? My fix is to make as many of them more specific, specifying at least `StandardError`, and trying to be more specific. ### Why did you choose this fix out of the possible options? No other ways of addressing this came to mind. I'd be happy to consider.
|
☀️ Test successful - status-travis |
Fix some rescue calls that do not specifiy error type. The problem I noticed was in style, several instances of `rescue` clauses that do not specify an exception type. This is noted in in the Ruby Style Guide as [Avoid rescuing the Exception class](https://github.com/bbatsov/ruby-style-guide#no-blind-rescues). My diagnosis was that at least some of those are leftover style. They are noted in `.rubocop_todo.yml`. To make sure, I asked on Slack. My fix is to make as many of them more specific, specifying at least `StandardError`, and trying to be more specific. No other ways of addressing this came to mind. I'd be happy to consider. (cherry picked from commit ff6b871)
Fix some rescue calls that do not specifiy error type. The problem I noticed was in style, several instances of `rescue` clauses that do not specify an exception type. This is noted in in the Ruby Style Guide as [Avoid rescuing the Exception class](https://github.com/bbatsov/ruby-style-guide#no-blind-rescues). My diagnosis was that at least some of those are leftover style. They are noted in `.rubocop_todo.yml`. To make sure, I asked on Slack. My fix is to make as many of them more specific, specifying at least `StandardError`, and trying to be more specific. No other ways of addressing this came to mind. I'd be happy to consider. (cherry picked from commit ff6b871)
* 1-16-stable: Version 1.16.6 with changelog fix uninitialized @use_gvp instance var warning no longer test Ruby 1.9.3 against rubygems master Merge #6708 Auto merge of #6697 - walf443:added_changelog_section, r=hsbt Merge #6687 Merge #6686 Auto merge of #6670 - bundler:colby/invite-stephanie-morillo, r=segiddins Auto merge of #6627 - agrim123:agr-fix-add-groups, r=deivid-rodriguez Auto merge of #6612 - hdf1986:readme-bundle-add, r=segiddins Auto merge of #6495 - bundler:segiddins/6491-extra-gem-platform-in-lockfile, r=segiddins Auto merge of #6493 - agrim123:agr-update-bundle-update-docs, r=colby-swandale Auto merge of #6310 - utilum:rescue_unspecified_exception, r=segiddins Auto merge of #6184 - arbonap:pa-check-in-gemfile-docs, r=indirect fix typo
5 participants
What was the end-user problem that led to this PR?
The problem I noticed was in style, several instances of
rescueclauses that do not specify an exception type. This is noted in in the Ruby Style Guide as Avoid rescuing the Exception class.What was your diagnosis of the problem?
My diagnosis was that at least some of those are leftover style. They are noted in
.rubocop_todo.yml. To make sure, I asked on Slack.What is your fix for the problem, implemented in this PR?
My fix is to make as many of them more specific, specifying at least
StandardError, and trying to be more specific.Why did you choose this fix out of the possible options?
No other ways of addressing this came to mind. I'd be happy to consider.