東方算程譚

Oriental Code Talk ── επιστημηが与太をこく、弾幕とは無縁のシロモノ。

目次

Blog 利用状況

ニュース

著作とお薦めの品々は

著作とお薦めの品々は
東方熱帯林へ。

あわせて読みたい

わんくま

  1. 東京勉強会#2
    C++/CLI カクテル・レシピ
  2. 東京勉強会#3
    template vs. generics
  3. 大阪勉強会#6
    C++むかしばなし
  4. 東京勉強会#7
    C++むかしばなし
  5. 東京勉強会#8
    STL/CLRによるGeneric Programming
  6. TechEd 2007 @YOKOHAMA
    C++・C++/CLI・C# 適材適所
  7. 東京勉強会#14
    Making of BOF
  8. 東京勉強会#15
    状態遷移
  9. 名古屋勉強会#2
    WinUnit - お気楽お手軽UnitTest

CodeZine

  1. Cで実現する「ぷちオブジェクト指向」
  2. CUnitによるテスト駆動開発
  3. SQLiteで組み込みDB体験(2007年版)
  4. C++/CLIによるCライブラリの.NET化
  5. C# 1.1からC# 3.0まで~言語仕様の進化
  6. BoostでC++0xのライブラリ「TR1」を先取りしよう (1)
  7. BoostでC++0xのライブラリ「TR1」を先取りしよう (2)
  8. BoostでC++0xのライブラリ「TR1」を先取りしよう (3)
  9. BoostでC++0xのライブラリ「TR1」を先取りしよう (4)
  10. BoostでC++0xのライブラリ「TR1」を先取りしよう (5)
  11. C/C++に対応した、もうひとつのUnitTestFramework ─ WinUnit
  12. SQLiteで"おこづかいちょう"
  13. STL/CLRツアーガイド
  14. マージ・ソート : 巨大データのソート法
  15. ヒープソートのアルゴリズム
  16. C++0xの新機能「ラムダ式」を次期Visual Studioでいち早く試す
  17. .NETでマンデルブロ集合を描く
  18. .NETでマンデルブロ集合を描く(後日談)
  19. C++/CLI : とある文字列の相互変換(コンバージョン)
  20. インテルTBBによる選択ソートの高速化
  21. インテルTBB3.0 によるパイプライン処理
  22. Visual C++ 2010に追加されたSTLアルゴリズム
  23. Visual C++ 2010に追加されたSTLコンテナ「forward_list」
  24. shared_ptrによるObserverパターンの実装
  25. .NETでマンデルブロ集合を描く(番外編) ── OpenCLで超並列コンピューティング
  26. StateパターンでCSVを読む
  27. 状態遷移表からStateパターンを自動生成する
  28. 「ソートも、サーチも、あるんだよ」~標準C++ライブラリにみるアルゴリズムの面白さ
  29. インテルTBBの同期メカニズム
  30. なぜsetを使っちゃいけないの?
  31. WPFアプリケーションで腕試し ~C++でもWPFアプリを
  32. C++11 : スレッド・ライブラリひとめぐり
  33. Google製のC++ Unit Test Framework「Google Test」を使ってみる
  34. メールでデータベースを更新するココロミ
  35. Visitorパターンで遊んでみたよ
  36. Collection 2題:「WPFにバインドできる辞書」と「重複を許す検索set」
  37. Visual C++ 2012:stateless-lambdaとSQLiteのぷち拡張
  38. 「Visual C++ Compiler November 2012 CTP」で追加された6つの新機能

@IT

  1. Vista時代のVisual C++の流儀(前編)Vista到来。既存C/C++資産の.NET化を始めよう!
  2. Vista時代のVisual C++の流儀(中編)MFCから.NETへの実践的移行計画
  3. Vista時代のVisual C++の流儀(後編) STL/CLRによるDocument/Viewアーキテクチャ
  4. C++開発者のための単体テスト入門 第1回 C++開発者の皆さん。テスト、ちゃんとしていますか?
  5. C++開発者のための単体テスト入門 第2回 C++アプリケーションの効率的なテスト手法(CppUnit編)
  6. C++開発者のための単体テスト入門 第3回 C++アプリケーションの効率的なテスト手法(NUnit編)

AWARDS


Microsoft MVP
for Visual Developer - Visual C++


Wankuma MVP
for いぢわる C++


Nyantora MVP
for こくまろ中国茶

Xbox

Links

記事カテゴリ

書庫

日記カテゴリ

懇親会ふぉろーの続き: function-try-blockでできること

class Derived : private Base {

  Other member;

public:

  Derived() : Base(0), member(1) {

    いろいろ準備

    if ( !準備おっけぃ ) throw bad_derived_err;

  }

};

 

ここで Base,Other のコンストラクト失敗はそれぞれ bad_base_err, bad_other_err

throwされるとしましょうか。

 

Derivedの利用者コードはどんなんなっちゃうでしょう:

 

try {

  Derived d;

  ...

} catch ( bad_base_err ex) {

  ...

} catch ( bad_other_err ex) {

  ...

} catch ( bad_derived_err ex) {

  ...

}

 

...ちょっとマテ。

利用者が本来知らんでもえぇBaseはおろか

知れるはずのないOtherにまつわる例外も捕まえんとあかんのかい!?

だったらコレ↓の方がまだマシちゃうんかい? ってことですよ。

 

// 例外を使わぬアナクロな方法

class Derived : private Base {

  Other member;

public:

  Derived() : Base(0), member(1) {

    いろいろ準備

  }

  bool is_ok() const {

    return Base::is_ok() && member.is_ok() && 準備おっけい;

  }

};

 

// 利用者 

Derived d;

if ( !d.is_ok() ) { 残念っしたー }

 

function-try-blockがあればそこらへんがスッキリするです。

// function-try-block で例外を差し替える
class Derived : private Base {
  Other member;
public:
  Derived() try : Base(0), member(1) {
    いろいろ準備
    if ( !準備おっけぃ ) throw bad_derived_err;
  } catch ( bad_base_err ex) {
    throw bad_derived_err(親の不始末);
  } catch ( bad_other_err ex) {
    throw bad_derived_err(おなかイタイ);
  }

};


// 利用者 

try {

  Derived d;

  ...

} catch ( bad_derived_err ex) {

  残念っしたー

}

 

これならコンストラクタで例外投げるのもアリちゃいますかしらね。

 

投稿日時 : 2011年2月22日 19:16

コメントを追加

# re: 懇親会ふぉろーの続き: function-try-blockでできること 2011/02/22 20:54 Chiharu

わー。例外安全以外のパラダイムでの反論。
確かに、内部実装のエラーをクライアント コードでハンドリングするのは違いますね。こうした観点だと RAII があっても function-try-block は必要ですね。用途が別物って感じで。
ところで、話それますけれど、例外を catch する際、参照で受けた方がスライシングの懸念がなくなるように思うのですが、あんまし気にしないものでしょうか。すみません。なんか重箱の隅っぽい指摘で。

# re: 懇親会ふぉろーの続き: function-try-blockでできること 2011/02/22 21:35 επιστημη

あー、chatchすんのはふつーconst XXX& で受けてます。
ここでは本筋でないのでズボラこきました。

# re: 懇親会ふぉろーの続き: function-try-blockでできること 2011/02/23 7:56 デフォルトの名無しさん

なるほど。ほんとうに例外型の変換を行いたいとすれば、コンストラクタでの
function-try-block が必要になってしまうので、 function-try-block を
サポートしない古いコンパイラで考えれば例外を使わないという結論になって
しまうことがあった、というのは無理もない話のような気がします。

しかし妥当な判断かどうかは大いに疑問が残るところです。(少なくとも
挙げられたコードだけでは、の話になってしまいますが。)

まず bool is_ok() const が代案になるのなら(外部で失敗の詳細による分岐を
可能とする必要が無いのなら)そもそも投げっぱなしで外部では catch (...)
あるいは catch (std::exception const& e) 、あるいは catch しない、で十分
であり、例外型の変換は必要にならないはずです。

また、例外型の分類方法として bad_base_err, bad_other_err を
bad_derived_err のような、失敗の原因ではなく投げる場所に応じた例外型に
わざわざ変換して再 throw するのはあまり意味のある変換だとは思いません。
http://www.parashift.com/c++-faq/exceptions.html#faq-17.6
> * Organizing the exception classes around the physical thrower rather
> than the logical reason for the throw: ...
...
> * Designing exception classes on a subsystem by subsystem basis: ...
このような考えで作られていない既存のコードと組み合わせる場合は問題に
なってしまいそうですけど。

個人的な経験ではクラス外部も含めて RAII を徹底することでほとんど
「 catch しない」で済ませらるように感じており、そのせいもあってむしろ
積極的に「 catch しない」済ませられるようにしていくのが正解なんじゃ
ないか、とまで考えています。
http://www.parashift.com/c++-faq/exceptions.html#faq-17.7

# re: 懇親会ふぉろーの続き: function-try-blockでできること 2011/02/23 20:10 επιστημη

# 引っ張るなーw 面白いから歓迎ですけども

> bool is_ok() const が代案になるのなら...例外型の変換は必要にならないはずです。

えぇ、失敗した理由を利用者に教えてあげたいなら
enum status { 準備おっけぃ=0, 親の不始末, おなかイタイ, やる気ねぇ ... };
status get_status() const;
bool is_ok() const { return get_status() == 準備おっけぃ; }
とかやるでしょね。呼び側は詳細知りたきゃget_status()するます。

> また、例外型の分類方法として bad_base_err,bad_other_err を
> bad_derived_err のような、失敗の原因ではなく投げる場所に応じた例外型に
> わざわざ変換して再 throw するのはあまり意味のある変換だとは思いません。

同意。"誰が"コケたかではなく、"なぜ"コケたかを返すが吉と思います。
なればこそprivateメンバのコンストラクト失敗を利用者に直接投げるのは愚策で、
一旦自分で捕まえて適切な「"なぜ"コケたか」に変換してre-throwすんでしょね。

> このような考えで作られていない既存のコードと組み合わせる場合は問題に
> なってしまいそうですけど。

激しく同意。例外設計コミで俺たちが全部こしらえるならどうにでもできっけど、
RAIIになってなかったりオレオレ例外投げたりするライブラリを相手にせにゃならんでのぉ。

# re: 懇親会ふぉろーの続き: function-try-blockでできること 2011/02/24 9:26 デフォルトの名無しさん

> # 引っ張るなーw 面白いから歓迎ですけども

記事の最後が「これなら~アリ」となっていて基本がナシであることを
ほのめかすような書き方になっていたり、発生場所に応じた例外型の分類を
例として挙げられていたりするので、初心者の方が読めばまた誤解が生じて
しまいそうだな、と思ってしまいました。

先のエントリ同様、この記事で挙げられたのは FAQ に反する、特殊な事情を
受けてのローカルな指針であることを示させてもらうのが目的です。

> えぇ、失敗した理由を利用者に教えてあげたいなら
> enum status { 準備おっけぃ=0, 親の不始末, おなかイタイ, やる気ねぇ ... };
> status get_status() const;

(また例への突っ込みなので噛み合っているものか不安ですが・・・)
これをやると、 Derived 内部に「親」や「おなか」が存在していることを
間接的に晒してしまうので、適切ではない場合が多いと思います。
(新しい private メンバが増えたら enum status を拡張するの?・・・とか)

> 同意。"誰が"コケたかではなく、"なぜ"コケたかを返すが吉と思います。
> なればこそprivateメンバのコンストラクト失敗を利用者に直接投げるのは愚策で、
> 一旦自分で捕まえて適切な「"なぜ"コケたか」に変換してre-throwすんでしょね。

同意されている点と、「なればこそ」とされた方針とがいまひとつ合致してない
ように読めてしまいました。

たとえば挙げられているコードの member がさらに内部実装で使っている
new に失敗したのなら std::bad_alloc が発生しますが、これはちゃんと失敗の
理由を示しているのでそのまま投げてしまえばいいと思います。

わざわざ変換~再 throw する必要があるのは、下位から投げられてくる例外が
望ましくない場合( std::exception の派生になっていないとか、
「"なぜ"コケたか」を示すためにより適切な例外型があるとか)だけでいいと
思います。

> RAIIになってなかったりオレオレ例外投げたりするライブラリを相手にせにゃならんでのぉ。

こういうライブラリを相手にするときはまず「 RAII に沿うようにする」
「アプリケーションに都合のいい例外に変換する」という目的だけのラッパーを
作って、アプリケーションコードでは「 catch しない」を基本とできるように
してしまうのがおすすめです。

タイトル
名前
URL
コメント