Feature #6639
closedArgumentError から ArityError を分離
Description
=begin
ArgumentError と TypeError の違いがわかりにくい、という話がありました( #6423 )。
違いがわかりにくい原因として、メソッドやブロックの呼び出し時に、次のような感じで、
エラーの発生する場所が混在しているため、という理由が考えられます。
(1) 実引数の個数が正しいかをチェック → ダメなら ArgumentError
(2) 実引数の型(期待するメソッドがあるか)をチェック → ダメなら TypeError
(3) 実引数の値をチェック → ダメなら ArgumentError
ArgumentError のサブクラスとして ArityError を作り (1) のエラーを ArityError に
すれば、各エラーの意味が明確化するのではないかと思います。
=end
Files
Updated by kosaki (Motohiro KOSAKI) almost 12 years ago
=begin
ArgumentError と TypeError の違いがわかりにくい、という話がありました( #6423 )。
違いがわかりにくい原因として、メソッドやブロックの呼び出し時に、次のような感じで、
エラーの発生する場所が混在しているため、という理由が考えられます。
(1) 実引数の個数が正しいかをチェック → ダメなら ArgumentError
(2) 実引数の型(期待するメソッドがあるか)をチェック → ダメなら TypeError
(3) 実引数の値をチェック → ダメなら ArgumentError
ArgumentError のサブクラスとして ArityError を作り (1) のエラーを ArityError に
すれば、各エラーの意味が明確化するのではないかと思います。
=end
ArityErrorを導入する事自体は+1。でも(2)に関してもNameErrorじゃない理由はなんじゃい(型はチェックしてなくてメソッドがあるかどうかしか見てない場合がほとんど)とか(3)に関してはArgumentErrorとRangeErrorの違いはなんじゃいとか色々と疑問があり、ここだけ切り出して議論するのが適切なのかやや自信がないところではあります
Updated by metanest (Makoto Kishimoto) almost 12 years ago
- File No6639.pdf No6639.pdf added
Updated by mame (Yusuke Endoh) almost 12 years ago
資料受け取りました。
が、ext の開発者がどう嬉しいのか理解できず、タイムアウトになる予感がします。
--
Yusuke Endoh mame@tsg.ne.jp
Updated by mame (Yusuke Endoh) almost 12 years ago
- Status changed from Open to Rejected
きしもとさん
7/21 の開発者会議にて、残念ながらこの機能は不採択と判定されました。
これを採択すると他にも細分化の要望が来るであろうことから、
Ruby として「例外を細分化する方針」をとるかどうかで議論が行われました。
しかしまつもとさんからその方針には「不安」があるとのことで、採択しない
方向となりました。
--
Yusuke Endoh mame@tsg.ne.jp