Skip to content
Add custom processing for warnings
Branch: master
Clone or download

Latest commit

Fetching latest commit…
Cannot retrieve the latest commit at this time.


Type Name Latest commit message Commit time
Failed to load latest commit information.
test Add support for :taint as regexp argument to Warning.ignore Jan 21, 2020
.gitignore Initial commit Aug 9, 2016
CHANGELOG Bump version to 1.0.0 Jan 21, 2020
MIT-LICENSE Initial commit Aug 9, 2016
README.rdoc Add support for :taint as regexp argument to Warning.ignore Jan 21, 2020
warning.gemspec Bump version to 1.0.0 Jan 21, 2020



ruby-warning adds custom processing for warnings, including the ability to ignore specific warning messages, ignore warnings in specific files/directories, deduplicate warnings, and add custom handling for all warnings in specific files/directories.

ruby-warning requires ruby 2.4+, as previous versions of ruby do not support custom processing of warnings.


gem install warning

Source Code

Source code is available on GitHub at


By default, requiring the library does not make changes to how ruby processes warnings, it just adds methods that allow you to customize the processing.

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. It can also take a symbol or an array of symbols, and will use an appropriate regexp. The supported symbols are:

  • :arg_prefix

  • :ambiguous_slash

  • :bignum

  • :fixnum

  • :keyword_separation

  • :method_redefined

  • :missing_gvar

  • :missing_ivar

  • :not_reached

  • :safe

  • :shadow

  • :taint

  • :unused_var

  • :useless_operator

Warning.process takes an optional path prefix and a block, and if the warning 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 operate intelligently, choosing the longest path prefix that the string starts with.

Warning.dedup deduplicates warnings, so that if a warning is received that is the same as a warning that has already been processed, the warning is ignored. Note that this should be used with care, since if the application generates an arbitrary number of unique warnings, that can lead to unbounded memory growth.

Warning.clear resets the library to its initial state, clearing the current ignored warnings and warning processors, and turning off deduplication.

By using path prefixes, it's fairly easy for a gem to set that specific 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. The Kernel#warn :uplevel option will make sure the warning starts with the filename.

Note that many of the warnings this library can ignore are warnings caused during compilation (i.e. when files are loaded via require). You should require this library and setup the appropriate warning handling before loading any code that could cause warnings.


# 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__)

# Ignore all uninitialized instance variable warnings in current file
Warning.ignore(:missing_ivar, __FILE__)

# Ignore all Fixnum and Bignum warnings in current file
Warning.ignore([:fixnum, :bignum], __FILE__)

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

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

# Deduplicate warnings

# Ignore all warnings in Gem dependencies
Gem.path.each do |path|
  Warning.ignore(//, path)




Jeremy Evans <>

You can’t perform that action at this time.