diff options
author | eileencodes <eileencodes@gmail.com> | 2020-08-06 13:25:11 -0400 |
---|---|---|
committer | Jeremy Evans <code@jeremyevans.net> | 2020-09-01 16:16:06 -0700 |
commit | 6e8ec9ab6da228ade70fe7d0dd16540d8f859f00 (patch) | |
tree | 779940e5bde3daddcd0f9fc6ac91fa509b64e1d6 /gems | |
parent | de10a1f3583adeeffd7f8bcf8f276e0a626ffa0c (diff) | |
download | ruby-6e8ec9ab6da228ade70fe7d0dd16540d8f859f00.tar.gz |
Support passing a category to `Warning.warn`
This change adds a `category` kwarg to make it easier to monkey patch
`Warning.warn`. Warnings already have a category, but that warning isn't
exposed. This implements a way to get the category so that warnings with
a specific category, like deprecated, can be treated differently than
other warnings in an application.
The change here does an arity check on the method to support backwards
compatibility for applications that may already have a warning monkey
patch.
For our usecase we want to `raise` for deprecation warnings in order to
get the behavior for the next Ruby version. For example, now that we
fixed all our warnings and deployed Ruby 2.7 to production, we want to
be able to have deprecation warnings behave like they would in 3.0: raise
an error. For other warnings, like uninialized constants, that behavior
won't be removed from Ruby in the next version, so we don't need to
raise errors.
Co-authored-by: Aaron Patterson <tenderlove@ruby-lang.org>
Diffstat (limited to 'gems')
0 files changed, 0 insertions, 0 deletions