C# と VB.NET の質問掲示板

■No80044 (774RR さん) に返信
> プログラムの論理的誤りに対して皆さんは例外を使うか assert を使うか、どっちでしょうか。

assert は DEBUG のみとかになっているケースも多いので、当該ビルドでデバッグしていれば誤りを検出できるなら assert の方が楽ですね。
モジュール・ライブラリとしてリリースビルドで提供して、結合した状態での確認が主となるなら、戻り値・例外としておいた方が、不具合の検出確率は上がるとも思っています。
（assert を組織内のテストに向けたリリースビルドで動くようにするというのもありかもしれませんが）

カバレッジを意識するような開発プロセスだと、throw をばらまいていると大変なことになるので、assert になりやすいかなぁ。
（非公開関数の throw の分岐まで通せと言われると地獄を見そう）


■No80087 (とっちゃん さん) に返信
> 元ネタについては、Jittaさんの一言が、一番しっくりくる気が。。。

「その行でブレークした状態で止めたい」だと捉えているので、catch ブロックに到達した時点で StackTrace で行番号を特定するだけでは不満の可能性もあるかな？と。
（最初の質問で括弧書き内とはいえ、「ソースコードの行が黄色くなる状態」と示していることが根拠）

そう思いながらも、変数の状態をウォッチで確認したいなどと言われだすと、現状は構造的に厳しいというのが正直な感想です。


> 個人的には、メッセージを出さない場面なら
> try{...}catch(System.Exception){} 
> とかやりますね。

局所的かつ、致命的なことが起きないと把握できている範囲ならありでしょう。
IOException と SecurityException など、継承元をまとめられないエラーハンドリングは確かに地獄ですし。

C# 6.0 の例外フィルターでまだマシに書けるようになったかもしれません。
（仕事柄、そちらにまだ移れていないので実感できていませんが…）


> FileStream のコンストラクタなんて9種類も例外出してきますからね。
> 必要な例外は全部個別対処もありですが、たぶんそうはならないだろうなぁ。。。
> と思います。

局所的に手を抜くか、
File I/O 系の catch ブロックをたくさん並べて Action （ラムダ）を実行する「例外ハンドリングユーティリティクラス」みたいなものを作るか、
C# 6.0 に移って例外フィルターを書くか

といったところですかね、確かに。

try
{
}
catch (Exception exception) when (exception is IOException || exception is SecurityException /* あといくつか書く */)
{
    // 既知の例外
}

カバレッジっすか・・・とりあえずウチでは今のところは求められていないのですが、悩ましい問題ですね。
投げられた例外がどこで捕らえられるかは、例外の性質上予期できないので難解ですし
（きっちりデバッグされていれば）絶対に発生しない catch 句の通過を求められたりしたらイヤんです。

組み込みマイコン上の C++ に関しては try/catch 使ったこと無いですねぇ・・・使いどころが無いというか。
客先でバグが出ても最終的には WDT でリセットさせるしか手が無いし。
組み込みマイコンソフトでは ROM 容量や実行速度の問題で、
ソースコード上に assert は書いてますが通常ビルドでは無効化していることがほとんどです。
挙動がおかしいとき、特定数個のファイルだけ有効化するように使っています。
(全ソースファイルの全部の assert を有効にすると ROM に入りきらなかったり・・・)

FileStream のような「失敗を例外で実装」している奴はしょうがないので try/catch してます。
この前書いたコードを探してみたら

try {
    using (FileStream f = new FileStream(fn, FileMode.Open, FileAccess.Read)) {
        sz = (UInt32) f.Read(image, 0, max_size);
    }
} catch (System.SystemException) { return 0; }
return sz;

でした。まあこんなもんでしょ。

そっか。オイラが例外機構を使わない/使いたくない理由はメインの業務がマイコンソフトだからか。
最近の言語 (Java/C# 等) でプログラム覚えた人だと違うのかなぁ。