PEAR::Error_Stackについて復習 - ぐらめぬ・ぜぷつぇんのはてダ(2007 to 2011)

GroupのTXのテストケースを書き始めて、いよいよエラーハンドリングについて抜き差しならない状況に追い込まれつつある。
というのも、TXの性格からして、内部で context userのroleやownerの判別をする。当然。となると、ファイルが壊れたとか以外の、論理的な妥当性チェックエラーがTX内部で発生する。これをハンドリングせねばなるまい。

で、久しぶりに
http://iteman.typepad.jp/blog/2005/11/index.html
や
http://blog.hawklab.jp/item-8.html
や
http://pear.php.net/manual/ja/core.pear.pear-errorstack.php
を眺める。

で、久保先生のErrorStack解説PDF：

エラーハンドリングの方針をアーキテクチャ設計時に決定すること。
方針がなければ失敗は目に見えている。

｡゜（ﾟ´Д｀ﾟ)゜｡
すみません。全然決定してなかったです。失敗ですか・・・！？

うう、なんでまだ決めてないのかというと、Loggerをどうしようかというのも有りますが、表示をどうするのかが今ひとつ決めかねていたからです。
例えば、内部で生成した「ログ用の」メッセージをそのままHTML画面に出す・・・のは当然NGですよね？例えば内部のパラメータとかが当然ログに出されないと困るのがあって、しかしHTML画面に出ちゃうと当然まずいわけです。
で、どうしよう・・・と思ってたんですよ。エラーコードに対して、ログ用のメッセージフォーマットとHTML画面用のメッセージフォーマットの二種類を用意するか？とも思ったりしました。

ただ、上の資料を眺めている内にようやくYakiBikiなりのポリシーが定まってきました。
まぁ当然入力値の書式的な妥当性チェックはエラーとはしません。ただ、例えばマスタデータのIDが入力値として渡された時、それが存在していなければ当然弾かなくてはなりません。ただしそれもエラーとはカウントできません。なぜなら、HTML画面に表示されているselectボックスやradio/checkboxからユーザーが選んだモノとは限らず、攻撃者が意図的に設定した適当な値である可能性があるからです。
それよりも、HTML画面でselect/radio/checkboxを表示する為にマスタから読もうとしたらファイルが壊れてた、などの方をエラーとして扱うべきとします。TransactionあるいはDaoの内部でファイル操作に失敗したのは確実にエラーとして扱うべきです。
では、内部の詳細はログで出力するとして、ユーザーにはどう表示すればよいのでしょうか？これが自分の中では問題だったのです。ですがようやく見えてきました。エラーコードだけを表示すれば良いものとします。
つまりユーザーにはエラーの詳細は知らせる必要はないわけです。「エラーが発生したと言っている、そのエラーコードはXXXXだ。」という情報がユーザにとって必要なバランスの良い情報である、とYakiBikiではすることにします。
エラーのハンドリングやPEAR_ErrorStackを使います。そのため、TXやDAOの戻り値がエラーオブジェクトであるか否かは判別する必要はありません。但し、正常値(trueやIDやデータ配列)か、異常値(falseやnull、空配列)かを呼び出し側で判別し、適宜エラーメッセージを表示します。これはつまり、rendererを操作できるAction/Event/などのレイヤー側の仕事になります。
では肝心の、PEAR_ErrorStackに積まれたエラーコードはどうやってHTMLに表示するか。これについてはSmartyの専用プラグインを作成し、それで実現する予定にします。
こんな感じ。

エラーが発生しました。
- エラーコード：XXXX

↑Smartyのプラグインで自動表示
↓Userモジュール側でメッセージを表示

!!Userの追加に失敗しました。!!

妥当性チェック、IDの存在チェックなどはErrorStackに積まれないので、全てモジュール側の制御になる。

↓Userモジュール側でメッセージを表示

!!Userの追加に失敗しました。!!
ユーザー名：XXXXは既に使われています。

よし。結論。えっと、今は返値だけちゃんと扱っていれば良し！ErrorStackの作り込みはTODOで後回し！！

・・・良いのか？若干の不安。