ruby-core

Issue #17122 has been updated by tenderlovemaking (Aaron Patterson).


jeremyevans0 (Jeremy Evans) wrote in #note-1:
> I don't think we should add a category keyword if the only usage is for deprecation warnings. If we are going to do this, I think:
> 
> * All warning messages emitted by the core and the stdlib should have a category added
>   * This requires we agree on category symbols

I think we have category symbols already:

  * https://github.com/ruby/ruby/blob/66efe373116d510c05d57964b5ffa47f1c6e565c/error.c#L153-L168
  * https://github.com/ruby/ruby/blob/66efe373116d510c05d57964b5ffa47f1c6e565c/test/ruby/test_module.rb#L31-L32

But `Warning.warn` doesn't know what category the message is associated with.

>   * This requires new C-API warning functions added that accept a category

I think this might depend on how many categories we have.  Right now we have specific C functions for the deprecated type:

  https://github.com/ruby/ruby/blob/66efe373116d510c05d57964b5ffa47f1c6e565c/error.c#L377-L405

> * Kernel#warn should accept a category keyword and pass it to Warning.warn
> 
> Having Warning.warn accept any keywords will break existing versions of the warning gem, but I can update that if this is accepted.
> 
> I don't think the benefits of adding this outweigh the cost, but I'm not strongly opposed to it.

I think the benefit is that developers can tell which warnings they should really heed without resorting to string parsing and specific warning investigation.  If you have the category, it's easy to test your app with Ruby version N and know what will break in version N+1 without resorting to string parsing.

Maybe we could agree that the format of "will be removed" messages is always the same, but that seems like a brittle contract.

----------------------------------------
Feature #17122: Add category to Warning#warn
https://bugs.ruby-lang.org/issues/17122#change-87055

* Author: eileencodes (Eileen Uchitelle)
* Status: Open
* Priority: Normal
----------------------------------------
Deprecation warnings and other warnings in Ruby have a category (:deprecated, etc) but those categories aren't exposed or accessible. In the most recent Ruby 2.7 upgrade at GitHub we monkey patched `Warning#warn` to be able to turn warnings into exceptions. However, there was no way to tell which warnings were deprecations and which were other types of warnings.

I want to expose the `category` on the `Warning` module so that I'm able to monkey patch `Warning#warn` and treat deprecation warnings differently from other warnings without using a regex the strings.

Here's an example program demonstrating what I'd like to get from Ruby by implementing this feature:

```ruby
module Warning
  def self.warn(msg, category: nil)
    if category == :deprecated
      raise msg 
    else
      super
    end 
  end 
end

def ivar
  Object.new.instance_variable_get(:@ivar)
end

# Doesn't raise, but warns with verbose set
ivar

# Raises an error
Object.new.tainted?
```

The PR I worked on with @tenderlove is here: https://github.com/ruby/ruby/pull/3418

It moves the `Warning` module to be written in Ruby, updates `rb_warning_s_warn` to pass kwargs, and adds a `category` to `Warning#warn`. 



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:[email protected]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>

Thread

Prev Next

In This Thread

Prev Next