このブログの更新は Twitterアカウント @m_hiyama で通知されます。
Follow @m_hiyama

メールでのご連絡は hiyama{at}chimaira{dot}org まで。

はじめてのメールはスパムと判定されることがあります。最初は、信頼されているドメインから差し障りのない文面を送っていただけると、スパムと判定されにくいと思います。

参照用 記事

Catyスクリプトの分岐と例外処理の議論 中間決算

「フローチャートからマゾ・テストまで」に対してKuwataさん曰く

なんだかんだいって檜山さんあなたこの事が書きたくて書きたくて仕方がなかったんじゃないんですか

えっ、アハハハハハ。… と、笑う以外の反応はしない。

えー、それはさておき、くだんのマゾ・テスト(自己テスト)ができる程度にパワーアップさせたCatyスクリプトは、ワイルドCatyスクリプト命名するつもりです。対照的/対称的に呼びたいのなら、通常のCatyスクリプトはテイムCatyスクリプトでしょう。山猫スクリプトと飼い猫スクリプトがいいかも。

山猫も飼い猫も、実行エンジンは同一で、パーザーを変えるだけです。山猫モードでは、使える構文コンストラクトが増えるので言語機能は増大します。その代わり、インタプリタが裸で立ち上がるので、明示的なロードなしではライブラリ/ヘルパー機能が使えません。

それで、議論が宙ぶらりんの例外のハナシなんですが、結論的に言うと、山猫スクリプトには完全な例外機構を入れて、飼い猫スクリプトでは限定的とします。限定的とは; 典型的エラー(例:Command Not Found, File Not Found, Tag Unmatched など)は特定して命名しますが、他のエラーは特に分類せず Internal Server Error 相当の Something Wrong に集約しちゃうような扱いです。スクリプト内での例外捕捉機能は付けません。全体の処理を放棄する例外を発生させることはできます。処理を続行はするが否定的な報告をしたいときは、null、false、あるいはエラータグ(@NG, @ERROR など)を使います(昔風ですね^^;)。

僕が例外に乗り気じゃない一番の理由は、例外の概念も使い方も難しいからです。例外をちゃんと使いこなせる技量ってのは相当なもんです*1。特に、チームとして例外規約を決めて、例外の無視/捕捉/再スローなんかを系統的に行ったりするのは難しい。比較的分かりやすい例外(?)は、やけくそでOSレベルでexitしてしまうことです。

たいしたことはしない/できないように設計され、習得の難易度を極力下げたいCatyスクリプトに、理解も使用もむずかしい概念を持ち込むのはいかがなものか? ということですね*2。しかし、ワイルドCatyスクリプトの場合は事情が少し違っていて、ある程度の知識とスキルを仮定するし、そもそも例外機構なしで自己テストは不可能です。強力で精密な例外ハンドリングが必要です。

これが、現状での判断と決定です。

*1:このことは、白紙の初心者に例外を教えたりアドバイスした経験がある方はうなずいてくれるかと。

*2:一種の構文糖衣として、例外の書き方をサポートすることは、なきにしもあらず。