Comment on this RCR (edit wiki page) | RCRchive home

RCR 219: add Kernel.warn!() for warnings with backtraces

submitted by discordantus on Sun Feb 22 2004 10:09:56 PM -0800

Status: pending

Abstract

There should be a Kernel method warn!(), a variation of Kernel.warn() which would print out a backtrace for debugging purposes.

Problem

It is often useful to know the exact point in your script from which a warning was issued. Currently, there is no standard method or framework for doing this.

Proposal

There should be a method added to the Kernel module, which prints not only the warning, but the location in the script that caused the warning.

Analysis

Usually, the bang at the end of a method name indicates that the object will be modified. You can extend that to imply danger, or something done more throughly. Kernel.warn!() implies both of these, as warnings given in this way would be for more dangerous conditions (though not warranting an exception) and would more thoroughly report the error (by including a backtrace).

Implementation

I imagine it would probably be written into the Kernel module, but here's an example of how it might be done in standard Ruby.

module Kernel
    def warn!(warning)
        warn( "Warning: #{warning}\n"+
            caller.map{|a|' '*8+"from "+a}.join("\n")
        )
    end
end

Vote for this RCR

I'm not sure that I'd want a complete backtrace, but I would want at least the caller's line and filename. -- Austin Ziegler

Okay... I figured a backtrace would be necessary because:

1. If you call it directly from within part of your script, you would want to know the line number and file from your script (Kernel.caller[0])

2. If the warning is in a function defined in a file you required/loaded, you would want to know where your script called it. (Kernel.caller[1])

3. The call to warn! might be buried a few functions deep, away from the data that caused the warning. Especially if you use recursive function calls.

Since it would be impossible to know which context the warning was issued from, it seemed to me that a backtrace would be simplest. If people think otherwise, though, I'll change the RCR. --Mark

Can I rant about the name? I don't think the "!" is a good choice in this case. This is not a "dangerous" method --gabriele.renzi

I agree. method! means that calling the method is dangerous, and calling warn isn't dangerous (or shouldn't be :-) -- David Black

Although I know that many tutorials call the bang methods "dangerous", I never thought of them in that way... To me, it more indicates the strength, or thoroughness of the method. That is, "chomp!" *really* chomps that string... as if by shouting the method name, you can get it to do more work :) Thinking about it this way, it makes sense to name the method "warn!", since it's doing more work, doing a more thorough job of it.

But that's just me. If the method name doesn't make sense to most people, it shouldn't be chosen. This RCR is pretty well tied to the method name, so if you don't like the name, please vote against it! :) --Mark

I like being able to get a backtrace from a warning, but I don't think an additional method is necessary. With a warning framework (RCR#180), it should be easy to add a backtrace to all warnings, but only have the backtrace displayed if the warn func chooses to display it.

-- Paul Brannan

Add comments here

Back to RCRchive.

RCR Submission page and RCRchive powered by Ruby, Apache, RuWiki (modified), and RubLog

Strongly opposed [0]
Opposed [0]
Neutral [3]
In favor [5]
Strongly advocate [0]