プロフィール

kosaki

Author:kosaki
連絡先はコチラ

ブログ検索
最近の記事
最近のコメント
最近のトラックバック
リンク
カテゴリー
月別アーカイブ
RSSフィード
FC2ブログランキング

スポンサーサイト このエントリーをはてなブックマークに追加

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。


スポンサー広告 | 【--------(--) --:--:--】 | Trackback(-) | Comments(-)

RubyとArgumentError このエントリーをはてなブックマークに追加

RubyのArgumentErrorってなんなんだろうか。正しい使い方が思いつかない。名前からすると「引数エラー」なのだが、IOやらスレッドやらの副作用がない世界だと引数が正しければ正しく動くはずなのであらゆるケースが ArgumentErrorに丸めることが出来てしまう(そして本当にあらゆる種類のArgumentErrorがあるように標準ライブラリからは見える)

これは困った事で ArgumentErrorを rescue しても何が起こったのかまわったく分からないのではリカバー処理の書きようがない。エラー処理が書けないぐらいならない方がましで、いっそ ArgumentError廃止したら?という気さえしてくる。

一方別の解法もある、エラーの種類毎にArgumentErrorのサブクラスをつくって判別できるようにすることである。Javaの IllegalArgumentExceptionや C#のArgumentException がこの方針であるように見える。

しかしサブクラス方針ってJavaの価値観としては美しいけど、Rubyの大クラス主義には反してる気がしなくもない。自分がライブラリつくる立場になった時に毎回 ArgumentErrorのサブクラス作りたいかというと疑問


・・・と、ここまで書いて下書きを放置していたのだが、まめさんが遙か昔にまったく同じ事を、しかも遙かに高いレベルで指摘しているのを気づいてしまったので続きを書く気が失せた


まめめも:Ruby の例外クラスは分類が粗すぎる or 細かすぎる
http://d.hatena.ne.jp/ku-ma-me/20090423/p1


補足1: Unixの世界の errno の EINVAL にも同じ問題があり、Linuxみたいにしょっちゅうシステムコールが拡張されてるケースでライブラリ作者にストレスが溜まる。(というか実際にglibc界隈から苦情を受けた経験がある)

関連記事


ruby | 【2012-02-10(Fri) 08:02:11】 | Trackback:(0) | Comments:(0)
  1. 無料アクセス解析
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。