「Catyスクリプトの分岐と例外処理の議論」、「続・Catyスクリプトの分岐と例外処理の議論」の続きの話。
というわけで、おおすじにおいて例外処理機構を入れる方向ですが、...
入れないとは言ってない、いずれ（[追記]どこかに[/追記]）入れます。ホント。
けど、スクリプト内でエラーハンドリングできないことは、それほどに緊急な問題だとは思ってないのです。実際に困るのは：
Catyのコマンドが例外を出さないわけじゃないです。コマンド宣言には例外宣言もちゃんとあります。ですが、例外は必ず実行を中止させてしまい、HTTPの500番にマップされちゃうのです（ドヒャー）。
こっちね。
一見、問題点が同じようですが、分けて考えることができます。コマンドがエラーを投げてもスクリプト内では捕捉できない、そうだとしてもシェルはエラーを捕まえることができます。「ユーザーが自由にエラーハンドリングできない」という問題は残るにしろ、とりあえずシェルが一番適切そうな対処をすることはできます。
エラー処理のカスタマイズを設定ファイルに書くという手はある、次のように。
しかしこれでは、パイプラインごとに個別のエラー処理は書けない。不便だ。ダメだ。
"errorHandle" : {
"404" : "redirect /errors/404.html",
"not_logged_in" : "redirect /login.html",
"invalid_form" : "print /form/retry.html",
...(省略)...
}
「ダメだ」と書いたのですが、当面の処置としてはこれもアリかな、と。現状、404 Not Found の処理が奇妙なことになってますが、caty.error('E404', message) のようなヘルパーAPIがCaty特有のエラーを（シェルに向けて）投げて、シェルがそれを捕まえて設定されたエラーページを送る、でもいいだろと。Catyで事前に定義されてない例外は500番にするしかないけど。
大域脱出の必要がないエラー報告、つまりパイプラインのお隣どおしの連絡にはタグを使えばいいし、場合分け分岐はタグディスパッチでできます。
さて、応急処置じゃなくてちゃんとやるにはどうするか？ -- 今日明日で結論を出すような緊急性はないので、状態と例外の双対性とかを使ってキレイっぽい解決を考えればいいかな、っと。コマンドが、readonlyモードのリソース（メモリとかファイルとかデータベースとかWebサービスとか）にアクセスするとき、直積スタンピングを使っています。これは、ほぼコモナドなんだけど、純正コモナドとは若干ずれてます。同様に、例外は直和スタンピングに対するほぼモナド。「ほぼコモナド」と「ほぼモナド」が（ほぼじゃなくて）完全に双対なので、対称的な扱いをしたほうが都合がいいでしょ。（[追記]最終的には対称にならないかもしれないけど、考えるときは対称的に考えて、現実的な要因から対称性を崩すかも、ってことです。[/追記]）
