エラーハンドリング＠PHP技術

※前回と同じく、主の理解していない部分が多く含まれています。
また、解はありませんので了承ください

前回エラーハンドリングについて書いたのですが、そもそもユーザー定義メッセージとエラーレベルとは関係ないとの指摘をいただいたので、考え直してみます。

まず、PHPシステム側のエラーと開発者側のエラー(出力メッセージ)とを分けて考えなければなりません。

PHPシステム側のエラーとは、Warningやparseエラーなどのことで、コンパイルエラーや実行時エラーのことを指します。

もう一方の開発者側のエラー(出力メッセージ)とは、予期しない値の入力や、関数仕様に合っていない使い方をしたときに検知して出力するものです。

これを踏まえて、今回は前回に調べそこねた「開発者側のエラーハンドリング」について調べ(考え)てみました。

まず、ぱっと思いつく方法

try,catchで例外出たら出力メッセージを出す。
Defineなどでエラーコードを予め定義しておいてそれを表示する

ううむ、それぐらいしか思いつきませんでした。
考えていくうちに、例外を受けるパターンとロジックの判定を利用するパターンで二つある気がします。

ちょっと脱線→
でも、HTTPのレスポンスコードってある意味出力メッセージの一種だと思う…ということを考えると、Defineの案に便乗して
・体系別に区分けしてメッセージの意味を定義する
っていうのも考えられると思います。

話を戻して…
エラーの取扱い方は構造的な意味では２つあります。

エラーを検知したその場で出力する。
エラー情報を返して上位の方でエラーを検知して出力する方法

エラーを検知したその場で出力する方法では、出力の一貫性が保ちにくい、汎用性がなくなるとという欠点があります。
一方、エラー情報を返して上位の方でエラーを検知して出力する方法では継承に対応出来ない、情報が隠蔽されないなどの欠点があります。

う〜む、構造に組み込むのは難しいです。まだそこのレベルまで達していないんだとおもいます。
とりあえず、開発者側のメッセージはエラーログクラスを別に用意して標準関数的な扱いで出力させようと思っています。
ユーザーに見せるメッセージは･･･「ただ今サービス時間外です」とか「もう一度ログインしてください」とか出力する時の為にユーザー情報出力クラス的なものが必要だと思いました。

調べていくと細かく分けている人がいました
→http://www.csus4.net/d/2005/05/22/errorhandling/

ビジネスロジックエラー(代替フロー)
システムエラー
入力エラー
プログラミングエラー
内部状態不整合エラー

おおー　ここまで分けられるとスッキリです。

→Exeptionってシステムエラー？開発者側メッセージ？どっちになるんだろう
実行時エラーだが、開発者メッセージの起点になる…的な？
→アスペクト指向プログラミングていう方法があるらしい

構成や仕様の話が主で、ポリシー的な記事が見当たりませんでしたので、期待はずれの記事になってしまったかもしれません。