Feature #6639: ArgumentError から ArityError を分離

• Status: Rejected
• Assignee: -
• Target version: -

[metanest (Makoto Kishimoto)]

=begin
ArgumentError と TypeError の違いがわかりにくい、という話がありました（ #6423 ）。
違いがわかりにくい原因として、メソッドやブロックの呼び出し時に、次のような感じで、
エラーの発生する場所が混在しているため、という理由が考えられます。
(1) 実引数の個数が正しいかをチェック → ダメなら ArgumentError
(2) 実引数の型（期待するメソッドがあるか）をチェック → ダメなら TypeError
(3) 実引数の値をチェック → ダメなら ArgumentError
ArgumentError のサブクラスとして ArityError を作り (1) のエラーを ArityError に
すれば、各エラーの意味が明確化するのではないかと思います。
=end

[kosaki (Motohiro KOSAKI)]

=begin
ArgumentError と TypeError の違いがわかりにくい、という話がありました（ #6423 ）。
違いがわかりにくい原因として、メソッドやブロックの呼び出し時に、次のような感じで、
エラーの発生する場所が混在しているため、という理由が考えられます。
(1) 実引数の個数が正しいかをチェック → ダメなら ArgumentError
(2) 実引数の型（期待するメソッドがあるか）をチェック → ダメなら TypeError
(3) 実引数の値をチェック → ダメなら ArgumentError
ArgumentError のサブクラスとして ArityError を作り (1) のエラーを ArityError に
すれば、各エラーの意味が明確化するのではないかと思います。
=end

ArityErrorを導入する事自体は＋１。でも(2)に関してもNameErrorじゃない理由はなんじゃい（型はチェックしてなくてメソッドがあるかどうかしか見てない場合がほとんど）とか(3)に関してはArgumentErrorとRangeErrorの違いはなんじゃいとか色々と疑問があり、ここだけ切り出して議論するのが適切なのかやや自信がないところではあります

[metanest (Makoto Kishimoto)]

• File No6639.pdf No6639.pdf added

[mame (Yusuke Endoh)]

資料受け取りました。
が、ext の開発者がどう嬉しいのか理解できず、タイムアウトになる予感がします。

--
Yusuke Endoh [e-mail]

[mame (Yusuke Endoh)]

• Status changed from Open to Rejected

きしもとさん

7/21 の開発者会議にて、残念ながらこの機能は不採択と判定されました。

これを採択すると他にも細分化の要望が来るであろうことから、
Ruby として「例外を細分化する方針」をとるかどうかで議論が行われました。
しかしまつもとさんからその方針には「不安」があるとのことで、採択しない
方向となりました。

--
Yusuke Endoh [e-mail]