Ruby Forum Ruby-core > Problem reported in Rdoc (Ruby 1.9) Rdoc for Ruby 1.8 works

Hi!

For my testing activities I use Rdoc when ever possible in he moment. 
After
"make install" on Windows in a MSYS generated version I use Rdoc to 
generate
everything possible in the generated file tree. This work fine using 
Rdoc for
Ruby 1.8. This time I tried to use Rdoc for Ruby 1.9 the first time 
(Ruby
generated from actual snapshot - 2007/10/22), but it fails (using Rdoc 
1.8
afterwards worked). The report:

 >>>>> Windows Console Output >>>>>
 >>>... lot of lines before this point ...
                      timeridconv.rb: mccc..........
                             unix.rb: mc.........
                              drb.rb:
                           e2mmap.rb: m.

RDoc failure in lib/ruby/1.9/e2mmap.rb at or around line 56 column 24

Before reporting this, could you check that the file
you're documenting compiles cleanly--RDoc is not a
full Ruby parser, and gets confused easily if fed
invalid programs.

The internal error was:

C:/ruby19/lib/ruby/1.9/rdoc/parsers/parse_rb.rb:1913:in `const_get':
uninitialized constant E2MM (NameError)
         from C:/ruby19/lib/ruby/1.9/rdoc/parsers/parse_rb.rb:1913:in 
`block in
parse_method'
         from C:/ruby19/lib/ruby/1.9/rdoc/parsers/parse_rb.rb:1912:in 
`each'
         from C:/ruby19/lib/ruby/1.9/rdoc/parsers/parse_rb.rb:1912:in 
`inject'
 >>>>> End Of Windows Console Output >>>>>

The refered lines in "e2map.rb" are:

 >>>>> Lines 50 to 70 in "e2map.rb" >>>>>
#
module Exception2MessageMapper
   @RCS_ID='-$Id: e2mmap.rb,v 1.10 1999/02/17 12:33:17 keiju Exp keiju 
$-'

   E2MM = Exception2MessageMapper

   def E2MM.extend_object(cl)
     super
     cl.bind(self) unless cl == E2MM
   end

   # backward compatibility
   def E2MM.extend_to(b)
     c = eval("self", b)
     c.extend(self)
   end

   def bind(cl)
     self.module_eval %[
       def Raise(err = nil, *rest)
  Exception2MessageMapper.Raise(self.class, err, *rest)
 >>>>> End of Lines 50 to 70 in "e2map.rb" >>>>>

I hope this information is somehow useful for you.

Wolfgang Nádasi-Donner

This looks like the same problem I had.  I submitted the patch below to
this list two or three weeks ago.  I've also submitted a bug report with
the patch on RubyForge.  The problem is that NameError is no longer a
StandardError in Ruby 1.9, so it isn't caught with a bare rescue

  David

Index: lib/rdoc/parsers/parse_rb.rb
===================================================================
--- lib/rdoc/parsers/parse_rb.rb  (revision 13610)
+++ lib/rdoc/parsers/parse_rb.rb  (working copy)
@@ -1909,9 +1909,13 @@
            container = container.find_module_named(name_t.name)
            if !container
              added_container = true
-            obj = name_t.name.split("::").inject(Object) do |state, 
item|
-              state.const_get(item)
-            end rescue nil
+            begin
+              obj = name_t.name.split("::").inject(Object) do |state, 
item|
+                state.const_get(item)
+              end rescue nil
+            rescue NameError
+              nil  # NameError is not a StandardError in Ruby 1.9
+            end

              type = obj.class == Class ? NormalClass : NormalModule
              if not [Class, Module].include?(obj.class)

Hi,

In message "Re: Problem reported in Rdoc (Ruby 1.9) Rdoc for Ruby 1.8 
works"
    on Tue, 23 Oct 2007 12:19:55 +0900, David Flanagan 
<david@davidflanagan.com> writes:
|
|This looks like the same problem I had.  I submitted the patch below to 
|this list two or three weeks ago.  I've also submitted a bug report with 
|the patch on RubyForge.  The problem is that NameError is no longer a 
|StandardError in Ruby 1.9, so it isn't caught with a bare rescue

Since NameError is for exceptions caused by bugs in the program, I
thought it should be handled explicitly, but this bug indicates moving
it out of StandardError bring more pain than gain.  I'd reconsider
this change.

              matz.

On 25.10.2007 01:03, Yukihiro Matsumoto wrote:
> Since NameError is for exceptions caused by bugs in the program, I
> thought it should be handled explicitly, but this bug indicates moving
> it out of StandardError bring more pain than gain.  I'd reconsider
> this change.
> 
>               matz.
> 

For what its worth, this idiom seems to be common in Rails apps:

The name is: <% obj.name rescue "Unknown" %>

If obj is nil, 1.8 handles it gracefully as the programmer intended, but 
in 1.9
this would crash the page (NoMethodError: NilClass.name). It's very 
short and
sweet, it would be a shame if it's not supported anymore.

It also shows up in methods that accept different types of objects via 
duck
typing (e.g. either a File or a filename string). Since duck typing is 
the
recommended way to develop in Ruby, and NameError is an integral part of 
that
(or at least one of the facilitating mechanisms), it shouldn't be 
considered as
only a bug indicator.