続・Catyスクリプトの分岐と例外処理の議論

Kuwataさん：

• http://return0.dyndns.org/log/2009/10/07#s_1

昨日のコメント欄：

田辺 2009/10/08 01:54

簡単に考え付くのは

loggedin |

　　{ NG => redirect /login.html } ← タグ分岐はエラーのみ

has_token |

　　{ NG =>> redirect /form/notoken.html }

is_valid |

...

どうでしょうか。

---

m-hiyama 2009/10/08 08:42

田辺さん、
この方式だと、「NGはエラーを表す」ことを言語仕様に組み込むことになるのでやりたくないです。タグの使い道はまったく自由にしたいので。

分岐条件が書いてないなら素通しさせるのも、間違い／見落としが混入しやすくなるのでやりたくないし。

状況が輻輳*1しているわけじゃないので、割と簡単に解決できると思いますが、実はあんまり（Kuwataさんに比べて）切実感がないのですよ。スクリプト短いもん。

田辺さんコメントへの応答のごとく、あんまりシリアスに捉えてないのですが、問題点があるのも確か。

まず可読性に関しては、そんなに酷くないだろうと思ってます。スクリプトのレイアウトをちゃんとすれば、左上から斜め下に見ていけば正常処理をたどれるし、タグのインデント位置を揃えておけば、対応するエラーは同列に並びます。

それより、「タグの使い道はまったく自由」とすると、エラーを表すタグの選択はユーザーに任され、正常／異常の区別はコンベンションに頼ることになります。言語機能に例外がないプログラミング言語では、だいたいそういうことになっていて、しょうがないっちゃしょうがないのですが、例外があれば問題は解決軽減できます。

誤解されないように注意しておくと、Catyのコマンドが例外を出さないわけじゃないです。コマンド宣言には例外宣言もちゃんとあります。ですが、例外は必ず実行を中止させてしまい、HTTPの500番にマップされちゃうのです（ドヒャー）。スクリプト内部で例外の捕捉とハンドルが出来ないのよね。

コマンドを書くプログラマからすると、正常値も異常値もどっちも出力（output）に流すのは違和感があるかな？ とも思います。「ダメだと思ったら例外投げる」スタイルのほうが書きやすいですし。

というわけで、おおすじにおいて例外処理機構を入れる方向ですが、例外で投げるデータ型考えるのって負担なんですよね。正常処理のデータは目的がハッキリしているので定義しやすいんですが、異常事態報告のデータって考えにくい。ある程度の規模のライブラリで、全体として整合的できれいな例外クラス階層を設計しようとか思うと、だいぶ鬱陶しいでしょう。モノグサの僕としては、そういう負担もなくしたいです。

*1:「輻輳」は「錯綜」をミスタイプして漢字変換されたものだと思いますが、それでも意味はだいたい通じるみたい。