Although it has never been a big problem for me to see the "no such 
method" error, here is something you could do for debugging:

$ cat error.rb
#!/usr/bin/env ruby

class Broken
   def method_missing(meth, *args)
     msg = "No method #{meth}."
     if instance_variables.include?("@" + meth.to_s)
       msg <<= " Forgot to attr_reader :#{meth}?"
     end
     raise msg
   end

   def initialize( value )
     @value = value
   end
end

puts Broken.new(3).value
$ ruby error.rb
error.rb:9:in `method_missing': No method value. Forgot to attr_reader 
:value? (RuntimeError)
         from error.rb:17

Guillaume.


Le 6 oct. 04, ? 11:04, James Edward Gray II a ?crit :

> On Oct 6, 2004, at 9:49 AM, Joachim Wuttke wrote:
>
>> Encouraged by your quick response, I try to explain better
>> what I meant in example 2:
>>
>> class Foo
>>     attr_reader ... # here I forgot :pos
>>     def initialize
>>         ...
>>         @pos = ...
>>     end
>> end
>> ...
>> blabla = someClass.someMethod.link_to_another_class.methods_pos.oof
>>
>> => system complains "no such method"
>>
>> Formally, the system is right: I forgot to declare the read
>> access method for the variable pos.
>>
>> But:
>> (1) the system should tell me which method in the above
>> chain causes the problem
>
> I was sure Ruby does this:
>
> james% ruby broken.rb
> broken.rb:9: undefined method `value' for #<Broken:0x1ca954 @value=3> 
> (NoMethodError)
> james% cat broken.rb
> #!/usr/bin/env ruby
>
> class Broken
>         def initialize( value )
>                 @value = value
>         end
> end
>
> puts Broken.new(3).value
>
> __END__
>
> Looks right to me.  Is that what you're seeing?
>
>> (2) as a naive programmer, with a background in other languages,
>> I do not think of pos as method. I think of it as variable.
>> Once the system does not find a method, it could check whether
>> there is a local variable of same name, and then print out
>> an error message like
>>    "no method 'pos', no read access to local variable 'pos'".
>
> In Ruby all instance variables are private, so there's really no need 
> for such distinctions.  A class defines its interface through its 
> methods.
>
> I think your misconceptions here are just a few Rubisms that haven't 
> quite sunk in yet.  Hopefully, you'll find the messages making more 
> sense over time.
>
> And until then, just yell if you need us...
>
> James Edward Gray II
>
>