8

いつ try と catch を使用するのが最適ですか? try and catch を使用して質問に答えたときに怒った応答がありました (-1 me もありました...)。Google で検索したところ、この記事とこのスタックオーバーフローの質問が見つかりました。

私はいくつかの例を挙げます：

  1. タイム ゾーン IDのドロップダウン リストがあり、ユーザーが自分のタイム ゾーンを選択すると、データベースが更新されます。他のアプリケーションでは、DB から値を取得し、ユーザーの現在の時刻と日付を再計算しています。DB 内のデータのスペルが間違っているというオプションがあります (DB 内のハードコーディングされた変更またはバグ)。私が使用しているユーザーの日時の変換方法では、try and catch を使用していますが、これは間違っていると言う人もいます。forループを使用してDBから値を確認できましたが、日時を変換するたびにコストがかかります...

  2. 次のコードを使用して、XML ファイルが適切にフォーマットされているかどうかを宣言する必要があります。

    protected bool IsValidXML(string xmlFile)
{
    try
    {
        XmlDocument doc = new XmlDocument();
        doc.LoadXml(xmlFile);
    }
    catch(XmlException ex)
    {
        ///write to logger
        return false;
    }
    return true;
}

    xml ファイルを確認する他の方法はありません。

  3. アプリケーションの一部をファイルに書き込んでいることがあります。ファイルに書き込むと、さまざまな理由で exeprtion が発生する可能性があります。書き込み中に他のプロセスがこのファイルを使用しているなどです。通常、私はこのコードを使用しています：

     using (StreamWriter w = new StreamWriter(fs))
 {
     try
     {
         w.Write("** (Line) " + someValue + " **" + Environment.NewLine);                       
         w.Flush();                       
     }
     catch(IOExeption ex){}
     finally
     {
         w.Close();   
     }
 }

結論として、try と catch を使用する方法と使用しない方法がいくつかわかりました。私が見た記事の一文には、例外が発生した場合は、それについて知る必要があると書かれていました。、しかし、一般的なアプリケーションを扱うとき、ほとんどの場合、例外が発生することはわかっていますが、ほとんどの場合、なぜそれが発生したのかを本当に知ることができないため、以前にそれをキャッチすることはできません (私が書いた例のように) 、だからいつトライ アンド キャッチを使用するのが最適か

ASP.NET の同じレベルで、ページには次のようにキャッチできるエラー イベントがあります。

this.Error += new EventHandler(Page_Error); //this = instance of System.Web.UI.Page

イベントはtry catch問題と同じですか??

4

6 に答える 6

4

例外を処理する方法は、例外の性質と例外が発生するコンテキストによって異なります。

賢明な人々は、このテーマについて優れた記事を書いています。

あなたの例について：

ケース 1 では、実際に防御的になりたいと思うかもしれません。ただし、その catch ブロックで賢明なことを行うようにしてください。

ケース 2 は合理的に見えますが、XML 文書を読み込んで捨てるだけです。それも処理するほうが理にかなっているでしょうか？

ケース 3 では、try finally を使用していますが、これは間違いなく try catch と同じではありません。あなたの特定の例では、 using ステートメントはすでにファイルが閉じられていることを確認しているため、それは必要ありません。

于 2013-10-28T16:13:32.717 に答える
1

例 1 については、コードを参照してください。あなたが何をしているのかについてより具体的な考えがなければ、コメントするのは難しい.

たとえば、そのコードの問題は、エラー状態が完全に隠されていることです。確かに、xml ファイルが良いか悪いかはわかりますが、なぜxml が良いか悪いのでしょうか? わかりません。try/catch が悪いというわけではありません。全体が間違ったレベルで書かれているということです。xml ファイルを読み取るコードを記述し、そのコードの周りでエラー処理を行うだけです。

例 3 では、有用な例外情報を飲み込んでいて、実際にはtry/catch で何もしていません。ストリームがブロックによって破棄されるときにストリームを閉じることは完全に処理されるため、ブロック内の.Close()呼び出しは完全に不必要です。finallyusing

要約すると、ここで学ぶ必要があるのは、try/catch ブロックが悪いということではないと思います。例外情報を飲み込むのが悪いということです。

于 2013-10-28T15:58:52.770 に答える
0

私は、try...catch に関するあなたの質問で人々が過去に抱えていた問題を要約し、将来的に役立つはずのいくつかの明確さを提供できると思います。

最初の 2 つの例は、データ検証エラーが原因です。データは、変換関数に渡される前 (例 1)、または XML ファイルを書き込もうとする前 (例 2) に、既知の検証エラーがないかどうかをチェックする必要があります。

例外処理にはかなりのオーバーヘッドがあるため、絶対に必要な場合にのみ発生する必要があります。try...catch パターンは、標準のデータ検証ではなく、予期しない (例外的な) エラーを処理するために設計されています。

例 3 は、ほぼ適切な使用法です。IOException のように、準備ができていない予期しないことが発生する可能性がある状況です。特定の例外をキャッチすることは、複数の catch ブロックや処理の失敗につながる可能性があるため、不適切な形式と見なされます。一般的な Exception オブジェクトをキャッチする方が優れており、例外処理コードで正確な種類の例外を判断して処理できます。

メソッドごとに try...catch を 1 つだけにするのがベスト プラクティスであるため、try...catch ブロックはストリームライターもカプセル化する必要があります。try...catch を使用する場合は、常に例外処理コードを含める必要があります。空の catch ブロックまたは空の finalize ブロックは悪い形式であり、コードや後でそれを維持しようとしている人を助けません。

    try
    {
       using (StreamWriter w = new StreamWriter(fs))
       {

           w.Write("** (Line) " + someValue + " **" + Environment.NewLine);                       
           w.Flush();                       
       }
    }
    catch(Exception ex)
    {
        //exception handling code here
    }
    finally
    {
       //any clean up code here. The using statement makes it unnecessary for the streamwriter
    }

これらすべてがいくつかの質問に答え、問題を明確にするのに役立つことを願っています.

于 2013-10-28T15:58:35.887 に答える
0

私の経験では、外部操作 (データベースやファイル システムとのやり取り、サードパーティ コンポーネントの使用など) には、try catch ブロックが必要です。私自身のコードでは、私自身のコードが生成する例外の数を制限するために、常にメソッドにガード句を入れようとしています。句は、保存メソッドの先頭に追加する必要があります。

要するに、コードのどこが間違っているかを示すために例外に頼るのではなく、最初に例外の可能性を減らすようにしてください。

于 2013-10-28T16:09:01.777 に答える