例外を握りつぶして bool で返すという闇のテクニック

最近のプロジェクトで本当によくこんなコードを見かけるんだけど

public bool Foo(...)
{
    try
    {
        // hogehoe
    }
    catch(Exception ex)
    {
        return false;
    }
}

こんなことして、.net のライブラリの応答方法とギャップがあるの気にならないのかな?
業務的な例外と、只のコーディングミスを混同してるし、標準ライブラリ(どころか組み込み型ですらそうだけど)例外からは逃げられないと思うんですが気のせいですかね?

で、案の定受け取った方のコードはこんな感じになってて、

...

try 
{
    if(!Foo())
    {
        return true;
    }
    // 以下処理が続く
}
catch(Exception ex)
{
    Log.Write(LogType.Error, ex.StackTrace);
    return false;
}

酷くなると呼び出し元は、戻り値すら見ないで処理続行してますね。ハイ。で、数行先で別の例外が発生するんですが、それをまた握りつぶして呼び出し元が最上位まで同じ事を繰り返すと。。。

そしてスタックトレースしか出力されてないですが、例外って

ex.ToString();

と書くと全部文字列で取れるんですが知らなかったんでしょうね・・・

まぁ、普通にトラブルは発生するんですが、こっちに連絡が来るときには原因と現象が乖離しまくった意味不明かつ珍妙奇天烈な状態で連絡がくるんですね。で、意味が分からずコードを見ると上の様なコードが大量に仕込まれてるわけです。困ったことに、出荷する時の検査工程では正常系は動くんですよね。ちょっと外部条件が変わった途端に謎の挙動を始めるんですが、理由が判明した時のがっかり感です。

例外は自分でcatchして握りつぶさないで何もしないか、受け取ったら自分の例外にして上位に投げましょう。