From: Massimiliano Mirra <list@...>
Date: 2002-10-01T00:33:23+09:00
Subject: On passing wrong objects to methods

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:in `meth'
	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)