2

次のコードスニペットに出くわしました。罪のない人を保護するために名前が変更されました：

    public void RunProgram()
    {
        System.IO.FileInfo fInfo = new System.IO.FileInfo(Application.StartupPath + "Program.exe");

        if (!fInfo.Exists)
        {
            System.Windows.Forms.MessageBox.Show("Program could not be found, please verify your installation.\n\nDetails:\n" + fInfo.FullName);
            return;
        }

        try
        {
            System.Diagnostics.Process  process = new System.Diagnostics.Process();
            System.Diagnostics.ProcessStartInfo pStart  = new System.Diagnostics.ProcessStartInfo(); 
            pStart.FileName = fInfo.FullName;
            pStart.UseShellExecute = true;
            process.StartInfo = pStart;
            process.Start();
        }
        catch
        {
            System.Windows.Forms.MessageBox.Show(string.Format("An error occurred trying to run the program:{0}", fInfo.FullName));
        }
    }

私はここでいくつか間違っていることを知っています：

  • 例外タイプは個別に処理されていません
  • エラーメッセージは十分な情報ではありません

これらについても説明しますが、私の主な質問は、try/catchブロックの直前にあるファイルの存在を確認することです。これは少し冗長だと思います。

例外処理のポイントは、予期しない状態をキャッチすることです。私はファイルがそこにあることを完全に期待しているので、存在チェックを削除し、それが私にとって合理的な解決策ではない場合は、例外処理にそれをキャッチさせます。

どう思いますか？

4

4 に答える 4

2

ファイルが存在しないことは、合理的に予測できるものです。UIレベルであるため（私はそう思いますMessageBox）、要求を健全性チェックし、ユーザーに直接伝えてキャンセルするのが理にかなっています。

コードの奥深くにいる場合（UIからいくつかのレベルが削除されている場合）、例外は正しいことですが、それでも最初にファイルの存在を確認して、適切なエラーを出す可能性があります。もちろん、ファイルの存在チェックはすぐにスレッドの競合状態になります;-p

于 2009-05-08T15:00:46.917 に答える
1

小切手を削除することに投票します。.Exists()

例外タイプの処理に関しては、私の通常のモードは、すべてをキャッチするための汎用例外ハンドラーから開始することですが、それらの例外がログに記録されることも確認します。次に、それを分解して、ログに基づいてさまざまな例外を処理します。

于 2009-05-08T15:01:46.493 に答える
0

私は常に例外を避けようとします。これは一般的に、例外の中断を有効にしてVisual Studioを実行する傾向があるためです。したがって、可能な限り例外を回避するようにしてください。

また、例外をスローするのに費用がかかる組み込みシステムでの作業にもかなりの時間を費やしました。これはC＃には当てはまらない場合があります。

于 2009-05-08T22:49:43.887 に答える
0

これは冗長であり、誤った安心感を与える可能性があります。同時実行性が原因で、FileNotFound例外が発生する可能性があることに注意してください。

参照：パラメータ検証が冗長であると見なされる場合がありますか？

于 2009-05-08T15:55:42.463 に答える