エラーハンドリングフレームワークを公開しました。

http://tricklib.com/cxx/dagger/trickerr.h

以下、上記ファイルのコメント中のデザインノートより...

このフレームワークはファンクションインターフェイスに制限されないエラー
情報ツリーを扱う為のものです。

一般的にエラーを機能の呼び出し元に返す方法としては...

・戻り値あるいはOUT型引数
・グローバル変数
・例外送出

...などと言った方法がありますが、戻り値の類ではファンクションインターフェ
イスに強く依存し同時にファンクションインターフェイスに制限を設けることに
なりさらにはコンストラクタ・デストラクタ及びコールバック関数などではしば
しばエラーの返却方法に困ります。

グローバル変数を使う方法は呼び出した機能のエラー情報がどのグローバル変数
に格納されているのかわかりにくくまた機能毎にエラー返却の為のグローバル変
数を設けるのも馬鹿げています。

戻り値やグローバル変数ではこの他にも無視していけない類のエラーが発生した
場合で、且つ呼び出し側も無視するつもりのないエラーであってもチェック漏れ
によってうっかり無視してしまうというような問題もあります。

例外送出では戻り値やグローバル変数のような問題はありませんが、例外送出を
行った時点で必ず処理を中断しなければならなくなるという問題があります。

一般的にエラーの返却方法としては上記に挙げた以外にも概ねエラー情報が唯一つ
のエラーしか扱えないという問題もあります。ある程度以上、複雑な処理ではエ
ラーがひとつ発生したからと言ってそこで即処理を中断するわけにはいきません。
実際、即処理を中断するつもりでもリソース解放やロールバック処理を行う必要
に迫られまたその最中にさらにいくつかのエラーが発生することもありえます。

関数呼び出しというものがツリーを形成する以上、エラー情報もツリーを形成さ
せるのがいいか悪いかは別にして少なくとも素直な設計と言えるでしょう。

以上のことを踏まえこのエラーハンドリングフレームワークでは次のような特徴
を持ちます。

・エラー情報は(スレッド別に)ツリーを形成可能。
・エラーは例外処理と同様に"送出"することで呼び出し元に返す。
・送出されたエラーはエラーリスナーがキャッチする。
・エラーリスナーにキャッチされなかった場合を除きエラー送出では処理は中断
  されない。(キャッチされなかった場合、次項の例外送出により中断される場合
  がある)
・エラーリスナーにキャッチされなかったり、いったんエラーリスナーにキャッ
  チされたものの最終的には放置されたままになってしまったエラーを例外とし
  て送出可能。(デフォルトでは例外送出を行われない。)
・エラー情報クラス及びエラーリスナークラスは自在にユーザ定義可能。

...とまぁ、以上のコンセプトで作ってみたわけですが、この手のものは実際に
いろんなプログラムに適用してみないとその善し悪しはなかなか分からないもの
ですし、使いながらブラッシュアップしていく必要もあるのではないかと考えて
います。

また、小規模のプログラムではこのフレームワークはオーバースペックになるこ
とが予想されるのでオススメしませんし、ソースコードはできるだけ簡潔な状態
に保つべきという観点からも小規模のプログラムではエラー情報はツリーモデル
ではなくシングルモデルが望ましいと考えます。

...自分自身でしばらく使ってみてから cppll で他の人の意見を訊いて見ようと思う。

追記

いろいろと考えてみて別に小規模のプログラムで採用するのも悪くないような気がしてきた。確かに小規模プログラムでエラー情報ツリーを扱うのはオーバーかもしれないけど、エラー情報としてはルートのエラーだけ処理するというスタイル(エラー情報自体はツリーモデルで形成されるが、処理スタイルとしてはシングルモデル)をとってもいいんだし、エラーリスナーを設置せずにエラー情報を投げっぱなしにしちゃっても別に構わないんだし。思ってたりよりもこのフレームワークは柔軟性が高そうだ。