東方算程譚

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

記事カテゴリ

書庫

日記カテゴリ

例外的にふぉろーのふぉろー

例外ネタでもうひとつ。

 

ま、そゆわけで例外投げるときゃ「誰がコケたか」じゃなく「なぜコケたか」がわかる例外投げようね、と。

 

もひとつのキモは「ちゃんと階層化しようゼ」です。

 

class おなかイタイ {};

class あたまイタイ {};

class あたまワルイ {};

class 電車止まってる {};

class コムギコカナニカダ {};

class 俺の妹がこんなに可愛いわけがない {};

 

なんて横並びに例外こしらえちゃうとcatch側がいい迷惑で:

 

try {

  Person p = 会社.人よこせ();

} catch ( おなかイタイ& ) {

  ...

} catch ( あたまイタイ& ) {

  ...

} catch ( 電車止まってる& ) {

  ...

}

 

なんてなcatch節をあーでもないこーでもないと並べにゃならんす。

 

try {

  Person p = 会社.人よこせ();

} catch ( 個人の問題& ) {

  おしおきだキサマ

} catch ( 外的要因& ) {

  それじゃ仕方ないねー

}

 

とか書けるように継承関係でカテゴライズしましょうね、と。

 

標準C++では ヘッダ<stdexcept>に例外用基底クラスがいくつか定義されてます:

 

exception : <exception> で定義された例外の総本山

  logic_error : 「そんなんじゃ仕事できんよ」的な

    domain_error : 領域/分野 (後述)

    invalid_argument : 「おかしな引数もらった」

    out_of_range : 「想定の範囲外」配列の上限超えてるとか

  runtime_error : 「仕事したらヘンな結果でちゃった」的な

    overflow_error : デカくなりすぎた

    underflow_error : ちっさくなりすぎた

    range_error : 想定された範囲に収まらなんだ

 

で、わしらが例外投げるとするとこの階層のどっから導出するかなんだけども、どうやらdomain_errorてのが領域/分野に特化したエラーてことで、アプリケーションあるいはそれに近いレイヤから投げるものはdomain_errorから導出するんが妥当なセンのようです。

あるいはruntime_errorあたりから。せめてexceptionじゃないと前述の「あーでもないこーでもない」を利用者に強いることになります。

# 最悪 catch (...) で捕まえられるけど肝心の「なぜコケた」がわからずじまい。

 

[追記] コメントで突っ込まれました。

 

domain_error」のdomainは「領域/分野」じゃなくて、数学でいう「定義域」ちゃうんかい、と。

あーなるほど、 domain_error=定義域の外 と解釈すれば logic_error の派生であるのに納得できますし、runtime_erroから導出されたrange_error=値域の外 との対応がつくです。

# だったら out_of_range out_of_domain がせーかいちゃうんかの ^^;

 

なので訂正。

 

で、わしらが例外投げるとするとこの階層のどっから導出するかなんだけども、この基準に合わせるかぎり、「ヘンなもんもらったので門前払い」ならlogic_error,「ヘンな結果こしらえたので引責辞任」ならruntime_errorあたりが妥当なセンのようです。

 

投稿日時 : 2011年2月24日 19:19

コメントを追加

# re: 例外的にふぉろーのふぉろー 2011/02/24 21:45 Chiharu

(継承入ると、さすがにサンプルコードの catch 文も参照になりますね。

例外の継承構造はいつも悩むところなんですが、いろいろ悩んだ結果、今は std::logic_error は使用せず、std::exception か std::runtime_error からの派生で落ち着いています。std::logic_error を選択しない理由は、仕事で組み込みをやっているせいか、論理エラーは設計ミスに起因するものとして全て assert で落としてしまうので。std::logic_error の使いどころはちょっと分かっていないです。C++ の ABI がちゃんと固まっている環境でライブラリをバイナリでやりとりするなら、公開 I/F 部分で std::logic_error を投げるのも良いのでしょうけれど。

# re: 例外的にふぉろーのふぉろー 2011/02/25 11:17 デフォルトの名無しさん

> アプリケーションあるいはそれに近いレイヤから投げるものはdomain_errorから導出

std::domain_error は std::range_error と共に errno の EDOM, ERANGE に
対応するもので、それぞれ数学的関数の定義域、値域エラーを示すもの、という
説が有力です。アプリケーションレベルの例外として使うことはあまりないかと
思います。
http://stackoverflow.com/questions/641064/what-is-a-domain-error

タイトル
名前
URL
コメント