memo/20080604

参考になるページを見つけたのでメモ。

リンク	備考
http://www.noppi.jp/diary/?date=20050906

ほほう、コンストラクタですら例外を使いたくないと。なるほど。
コンストラクションの成否を別メソッドで通知可能にすると。ほほう。

私もC++では例外は、プロセスが自決するときにしか使いたくないと思っておりました。
C++では例外を使うと、4～6％遅くなるという情報があります(リップマン C++オブジェクトモデル)。

リソースの確保はコンストラクタで行うのが正論(と、ストラウストラップ氏が言ってたらしい。ソースは確か岩谷氏？が訳したC++の発展経緯の本だったような)。
だから、「コンストラクタでは何もせず、実質初期化を行う別メソッドを作る」のは好きじゃない。

で、参照先の意見(記述)を自分なりにこねくり回して解釈してみると、
コンストラクタ失敗は例外を返すのが「言語仕様」であり「普通」だけど、それはコンストラクタで失敗するのが「異常」であるクラスでの話であると。そういうことですな。たぶん。

たとえばネットワーク接続のような、簡単に失敗してしまうリソースを確保するコンストラクタでは、上記参照先のような方法をとるのが賢いのかもしれないですね。

そうすれば、
今までの俺ルール

(1)メモリ確保失敗など、重大な例外は全員スルーパスして、ctr0でのデフォルトキャッチャーに任せる。
(2)そんでプロセス自身は異常終了し、監視ツールで拾う。
(3)軽微な理由でコンストラクタが失敗するクラスの場合、呼び側はコンストラクションにtry～catchをかます。

を、こう変更できます。

(3'-1)軽微な理由でコンストラクタが失敗するクラスの場合、軽微な理由で失敗しても例外は返さない。
(3'-2)そのかわりに成否を知るためのメソッドを用意する。呼び側はコンストラクション後に適切にチェック。

---

(補足)テストでは規定ハードにて最大データ(最大負荷)を試すから、実運用でメモリ不足が起こることは基本的にありえない。

です。