Project

General

Profile

Actions

Feature #3916

closed

Add flag to ruby to make warnings fatal.

Added by docwhat (Christian Höltje) over 13 years ago. Updated over 6 years ago.

Status:
Closed
Target version:
[ruby-core:32713]

Description

=begin
I have a feature request: Please add a flag to the ruby command line to make warnings fatal.

It would be really handy when debugging and testing to make warnings fatal.

It's not always obvious what bit of code is causing the code that has the warning to execute. Having a full exception style trace back is very handy.

In addition, if you're doing tests, it would be good to have it raise an exception if a warning is fired. See http://stackoverflow.com/questions/660737/can-you-ask-ruby-to-treat-warnings-as-errors for an example.

Thanks!
=end

Actions #1

Updated by tenderlovemaking (Aaron Patterson) over 13 years ago

=begin
I'm not sure this is necessary. For example, sprintf() will raise an exception if in debug mode:

irb(main):001:0> $-w = true
=> true
irb(main):002:0> "foo" % 10
(irb):2: warning: too many arguments for format string
=> "foo"
irb(main):003:0> $DEBUG = true
=> true
irb(main):004:0> "foo" % 10
Exception ArgumentError' at (irb):4 - too many arguments for format string Exception ArgumentError' at /Users/apatterson/.local/lib/ruby/1.9.1/irb/workspace.rb:80 - too many arguments for format string
ArgumentError: too many arguments for format string
from (irb):4:in %' from (irb):4 from /Users/apatterson/.local/bin/irb:12:in '
irb(main):005:0>

Maybe we should just update code to raise an exception when in debug mode like sprintf() does.
=end

Updated by nahi (Hiroshi Nakamura) about 12 years ago

  • Description updated (diff)
  • Category set to core
  • Assignee set to matz (Yukihiro Matsumoto)
Actions #3

Updated by shyouhei (Shyouhei Urabe) about 12 years ago

  • Status changed from Open to Assigned

Updated by drbrain (Eric Hodel) about 12 years ago

Sometimes when I use Kernel#warn in my code it is a message the user may not be able to do anything about, such as a deprecation message in library "a" that is used in library "b" that has not yet been updated, but the user wishes to use. Turning these into exceptions would break this use of warnings.

Updated by trans (Thomas Sawyer) about 12 years ago

@drbrain (Eric Hodel) Wouldn't using priorities and setting such a warning to a very low priority solve this?

Updated by drbrain (Eric Hodel) about 12 years ago

There are no priorities for warnings at present, so any code using warnings would need to be updated to take advantage of the feature, breaking backwards compatibility.

Existing uses of #warn could be set as "lowest priority" which makes the feature not very useful since only new code will opt in, and the exception will only be useful when ruby is run with -d, which is rare.

Updated by trans (Thomas Sawyer) about 12 years ago

It wouldn't break backward compatibility, but it would take time for libraries to adjust to take the most advantage of it. And yet, any library with active development will likely adjust very quickly.

I would expect existing uses of warn to be set at "nominal priority" -- just below the error threshold. Although I imagine one could make the case that we should insert one priority layer between the two which would help make them a little more useful with libraries that haven't yet adjusted.

Updated by mame (Yusuke Endoh) over 11 years ago

  • Target version set to 2.6

Updated by matz (Yukihiro Matsumoto) over 6 years ago

  • Status changed from Assigned to Closed

Now we can implement the feature by redefining Warning.warn.

Matz.

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0