From: Yusuke ENDOH <mame@...>
Date: 2010-03-03T20:18:22+09:00
Subject: [ruby-core:28440] Re: [Bug #2830] Some methods raise 	ArgumentError instead of TypeError

Hi,

2010/3/3 Yukihiro Matsumoto <matz@ruby-lang.org>:
> |Some methods of Ruby 1.9 expect integers/reals and call internally nurat_int_value/nurat_int_check. These functions raise an ArgumentError when the argument is not an Integer, instead of a TypeError.
> |Unless there is objection, I will commit the following patch (and fix RubySpec):

Agreed.


> Go ahead.  I am thinking of making TypeError subclass of
> ArgumentError, since every TypeError should occur in relation to any
> argument.  How do you (guys) think?


I really agree with your problem awareness.

Some TypeErrors seem to occur regardless of argument:

  0.dup                      #=> can't dup Fixnum (TypeError)
  Class.allocate.superclass  #=> uninitialized class (TypeError)
  class C
    def _dump(x); 1; end
  end
  Marshal.dump(C.new)'       #=> _dump() must return string (TypeError)

We can change them to RuntimeError, etc, of course.


However, I think we need more drastic restructuring of Exception
classification.  Even currently, ArgumentError occurs in too many
cases.  Rescue'ing ArgumentError is even harmful because it may
hide unexpected ArgumentError.
(http://d.hatena.ne.jp/ku-ma-me/20090423/p1)

And, I said in [ruby-core:28003] TypeError and NoMethodError
should not be distinguished in some cases.  It means Exception
does not make hierarchy.  Without multiple inheritance, it can be
implemented by representing Exception as mix-in, I think.

So, why don't consider the design carefully towards 2.0?

Thanks,

-- 
Yusuke ENDOH <mame@tsg.ne.jp>