A common complaint seems to be that, when something inside a method
bombs because the wrong object was passed, it’s not easy to track down
the cause. For example:
x = obj.some_method # returning nil
y = obj.some_method # returning 1
[many LOC]
def meth(s)
return s + "addition"
end
p meth(x)
-:5:in meth': undefined method+’ for nil (NameError)
from -:8
Or also:
p meth(y)
-:5:in +': String can't be coerced into Fixnum (TypeError) from -:5:inmeth’
from -:8
If you’ve got little experience with Ruby, you’ll probably be puzzled.
Heck, even if you’ve got experience, you’ll probably be puzzled from
time to time.
[Enter humble proposal]
Could ruby (with, say, -w) provide not only a dump of the call stack,
but also some dump of the offend(ed|ing) object? Like this:
-:5:in meth': undefined method+’ for nil (NameError)
from -:9
···
Variable `x’ refers to an object of NilClass, was last assigned on
line 2, and responds to:
[“to_a”, “nil?”, “|”, “to_i”, “&”, “^”, “inspect”, “to_s”, “dup”,
“eql?”, “protected_methods”, “==”, “frozen?”, “===”, “respond_to?”,
“class”, “kind_of?”, “send”, “instance_eval”, “public_methods”,
“untaint”, “id”, “display”, “taint”, “hash”, “=~”,
“private_methods”, “is_a?”, “clone”, “equal?”, “singleton_methods”,
“freeze”, “type”, “instance_of?”, “send”, “methods”, “method”,
“tainted?”, “instance_variables”, “id”, “extend”]
That would help pinpoint the problem more quickly. (Of course that
error message presumes a lot of runtime information. I don’t know
enough about internals to tell if things like variable names and
places of assignments can be traced, nor if tracing can be easily
added in some `diagnostic’ mode at the expense of performance.)
Massimiliano (bard on IRC)