This post originated from an RSS feed registered with Ruby Buzz
by Daniel Berger.
Original Post: Structured Warnings
Feed Title: Testing 1,2,3...
Feed URL: http://djberg96.livejournal.com/data/rss
Feed Description: A blog on Ruby and other stuff.
One of the things that has come up in the past on IRC, ruby-talk, and even during a hallway conversation at RubyConf 2005 is the notion of structured warnings.
What do I mean when I say "structured warnings"? Well, at the moment there's no warning hierarchy in the same manner as we have an Exception hierarchy, i.e there's no Warning class, with a bunch of subclasses like StandardWarning, RuntimeWarning, etc. You just call "warn 'Look out!", and a warning appears as a string.
However, there are times when you want to suppress certain warnings. Perl lets you do this via the "no warnings" pragma, where you can voluntarily suppress certain types of warnings, e.g. "no warnings 'uninitialized'" (my personal favorite). There's no such mechanism in Ruby to do this.
Based on an old thread we've come up with something like this:
# Disable 'uninitialized' warnings permanately
UninitializedWarning.disable
DeprecatedMethodWarning.disable
foo.bar # yes, yes, I know it's deprecated, shut up.
end
That would allow you to disable a particular warning either until the end of the program, or only for the given block. It would also let you be more explicit in the types of warnings you wanted to raise in your own code. For example, say you've refactored one of your libraries, and want to replace your poorly named "foo2" method with the "foo_with_ham" method. You could then do something like this:
def foo2(*args)
warn DeprecatedMethodWarning, "use foo_with_ham instead"
...
end
Then, users of your old code could suppress that warning if they so chose.
Previous Topic
