Issue #12299 has been updated by Jeremy Evans.


Yukihiro Matsumoto wrote:
> I like the basic idea. I can be fundamental of higher level abstraction.
> My only concern is the name. `Warning` may be too generic and cause conflict.

How about using `RubyVM::Warning`?

Koichi Sasada wrote:
> If C extension shows warning, we can't stop with filen names because the file is caller's file (maybe not a problem because we should specify caller's file).

I don't think this is a problem.  If the user is calling a C extension that raises a warning, the problem is in the caller's file, or they need to fix the C extension.

> Now, passed |message| is a string like ": ". Should we pass separated objects like |file, line, message|?

I don't think so.  Because the data originates as a string, you could only get that information from splitting the string, which the user could easily do themselves.

> Do we need other information like backtrace?

I think `caller` would provide this information.

> Should we filter also with line? (over spec?)

I think the current patch allows this, since it just works on string prefixes and warning strings start with file and then line.  Filtering by line would be fragile, as even non-code changes like modifying comments can modify line numbers.

----------------------------------------
Feature #12299: Add Warning module for customized warning handling
https://bugs.ruby-lang.org/issues/12299#change-59196

* Author: Jeremy Evans
* Status: Open
* Priority: Normal
* Assignee: 
----------------------------------------
This is another attempt to provide the same type of support for customized warning handling as #12026.  matz had a couple of issues with #12026.  First, he did not like the introduction of a new global variable.  Second, he wanted the ability to control warning handling on a per-gem and/or per-class basis.

The approach in this patch adds a Warning module instead of using a global variable, and allows for per-gem customization by using separate processing for separate gems based on the path prefix in the warning message.  I don't think per-class warnings are possible without major changes.

This changes all warnings raised call to Warning.warn, which by default does the same thing it does currently (rb_write_error_str).  You can override Warning.warn to change the behavior.

To provide a common API that can be used to modify warnings, add a lib/warning.rb file, which offers three methods: Warning.ignore, Warning.process, and Warning.clear.

Warning.ignore takes a regexp and optionally a path prefix, and ignores any warning that matches the regular expression if it starts with the path prefix.

Warning.process takes an optional path prefix and a block, and if the string starts with the path prefix, it calls the block with the warning string instead of performing the default behavior. You can call Warning.process multiple times and it will be operate intelligently, choosing the longest path prefix that the string starts with.

Warning.clear just clears the current ignored warnings and warning processors.

By using path prefixes, it's fairly easy for a gem to set that warnings should be ignored inside the gem's directory.

Note that path prefixes will not correctly handle warnings raised by Kernel#warn, unless the warning message given to Kernel#warn starts with the filename where the warning is used.

Note that the current implementations of Warning.ignore, Warning.process, and Warning.clear in the patch are not thread safe, but that can be changed without much difficulty.

Examples from the RDoc in the patch:

~~~
# Ignore all uninitialized instance variable warnings
Warning.ignore(/instance variable @\w+ not initialized/)

# Ignore all uninitialized instance variable warnings in current file
Warning.ignore(/instance variable @\w+ not initialized/, __FILE__)

# Write warning to LOGGER at level warning
Warning.process do |warning|
  LOGGER.warning(warning)
end

# Write warnings in the current file to LOGGER at level error
Warning.process(__FILE__) do |warning|
  LOGGER.error(warning)
end
~~~


---Files--------------------------------
0001-Add-Warning-module-for-customized-warning-handling.patch (10.1 KB)


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

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