ルールが変わったんだよ

http://d.hatena.ne.jp/akiramei/20051225
より．
これまでアプリケーション固有の例外を定義しようと思った場合にはApplicationExceptionを派生したクラスを定義していた訳ですが，FxCopによると今後はSystem.Exceptionを派生したクラスを使え，とのこと．うそーん．
たしかに
http://msdn2.microsoft.com/ja-jp/library/seyhszts.aspx
にもこんなことが書いてあるなー

ほとんどのアプリケーションでは、Exception クラスからカスタム例外を派生します。本来、カスタム例外は ApplicationException クラスから派生しなければならないと考えられていましたが、実際には、このことで大きな価値が付加されたことはないようです。

大きな価値が付加されることはない……のかなぁ？少なくともクラスライブラリ側がApplicationException及びそれを派生した例外を送出することはない(はず)なので，

class Program
{
  static void Main()
  {
    try
    {
      // なんらかの処理
    }
    catch(ApplicationException ae)
    {
      // アプリケーション固有の例外はここで一括処理
      // (イベントログを吐くとか)
    }
    catch(Exception e)
    {
      // クラスライブラリが送出した例外
      // (出来る範囲でログ出力，またはFrameworkに任せるとか)
    }
  }
}

みたいな感じで切り分けるられるのは魅力だと思うんだけど．

(クラスライブラリでない)実プロジェクトにおいて，例外クラスの設計を適切に階層構造で定義できるようなところであればいいんですが，実際は場当たり的に作られるのがほとんどだと思います．そんなとき，とりあえずApplicationExceptionを継承してもらうとか，あるいはApplicationExceptionそのものを使ってもらうとかにしておけば，ハンドリングする側は楽だと思います．逆にExceptionを使われちゃうと……ハンドリングする側はExceptionをキャッチするしかなくなっちゃうし，実際に困る状況が発生しそうな気がする．

……いや，そんなことはないのかな？やはり基本に立ち戻って，例外クラスの設計を事前にきちんと行っておけばいいのかな？単にこれまで書いたプログラムをどう扱ったらいいかわからなくて混乱しているだけなのかも？
すこし落ち着いて考えようと思います．