[ruby-core:28441] Re: [Bug #2830] Some methods raise ArgumentError instead of TypeError

Hi,

(2010/03/03 20:18), Yusuke ENDOH wrote:
> 2010/3/3 Yukihiro Matsumoto <[e-mail]>:
>> |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.

I agree with marcandre too.

>> 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?

But I fully agree with Yusuke;
This change will be a system wide change.
I think it won't be concluded before 1.9.2 release.
So applying it to trunk should be carefully.

-- 
NARUSE, Yui  <[e-mail]>