1

データベースに記録された画像名を確認する方法があります。そのようなものがある場合は、記録されたパスで画像をロードしようとします。ない場合は、デフォルトの画像を読み込みます。

最初に、返された例外が何であれ、try-catchブロック内にメソッド全体がありました。catch(Exception ex)Error loading image

    if (File.Exists(imgPath + "\\" + imageName))
    {
        try
        { 
            using (var temp = new Bitmap(imgPath + "\\" + imageName))
            {
                pictureBox1.Image = new Bitmap(temp);
            }

            if (pictureBox1.Image.Width > defaultPicBoxWidth)
            {
                pictureBox1.Width = defaultPicBoxWidth;
            }
        }
        catch (Exception ex)
        {
            logger.Error(ex.ToString());
            MessageBox.Show("Error loading image!", "Error", MessageBoxButtons.OK, MessageBoxIcon.Error);
        }
    }

次に、データベースにレコードがある場合があることがわかりましたが、何らかの理由でファイルが欠落している可能性があるため、そのチェックを追加します。

if (imageName != null && !File.Exists(imgPath + "\\" + imageName))

今度は、この場合にも適切なメッセージが必要です。try-catch私は、いくつかのブロックを使用してそれらの部分を処理するか、例外をスローして、メソッドが呼び出された場所から例外を処理することができるという結論に達しました。

私は2番目のオプションを選択しましたが、コード全体は次のとおりです。

    if (imageName != null && !File.Exists(imgPath + "\\" + imageName))
    {
        throw new FileNotFoundException(); 
    }

    if (File.Exists(imgPath + "\\" + imageName))
    {
        //try
        //{ 
            using (var temp = new Bitmap(imgPath + "\\" + imageName))
            {
                pictureBox1.Image = new Bitmap(temp);
            }

            if (pictureBox1.Image.Width > defaultPicBoxWidth)
            {
                pictureBox1.Width = defaultPicBoxWidth;
            }
        //}
        //catch (Exception ex)
        //{
        //    logger.Error(ex.ToString());
        //    MessageBox.Show("Error loading image!", "Error", MessageBoxButtons.OK, MessageBoxIcon.Error);
        //}
    }

そして、これは私がメソッドを呼び出す場所です:

try
                {
                    //The name of the method described above
                    LoadSavedOrDefaultImage(imageInfo, entity.Picture, txtCode.Text, imageLocation);
                }
                catch (FileNotFoundException ex)
                {
                    logger.Error(ex.ToString());
                    MessageBox.Show("Error loading image! The file wasn't found.", "Error", MessageBoxButtons.OK, MessageBoxIcon.Error);
                }
                catch (Exception ex)
                {
                    LogErrorAndShowMessage(ex, Resources.ERROR_LOAD);
                }

私はこれの方が好きですが、その理由を正確に言うことはできません。一般的な質問は、例外を処理するこの正しい方法ですか。try-catchそして、より具体的なもの-私の正確なケースでは、ブロックを配置するのに適した場所はどこですか? メソッド自体の本体にいることは理にかなっています。そうすれば、try-catchメソッドを呼び出すすべての場所にこれらのブロックを書き込む必要がなくなり、この方法でさらにカプセル化されるからです。また、現在は2つのtry-catchブロックがありますが、将来ロジックが変更された場合は、さらに異なる例外をスローしたい場合があります。あなたの意見を読むために。

4

2 に答える 2

3

  1. 「例外を処理するのに最適な場所はどこですか」という一般的な質問への回答として、答えは簡単です。常に例外が発生したポイントに最も近い場所で例外を処理します。

    これは、例外を処理するために必要なほとんどの情報が得られる場所であり、コードの依存関係も抑えます。例外があまりにも多くのレベルで発生するようにすると、その上位レベルのコードは下位レベルのコードの実装の詳細を知る必要があり、結合が増加し、抽象化が破壊されます。

    例外を処理するのに十分な情報がない場合、または何をすべきかわからない場合は、例外をまったく処理しないでください。代わりに、最終的にそれを処理できるコードに到達するか、失敗した場合は、エラー メッセージを表示したり、ログ ファイルに書き込んだり、ダンプを開発者に送り返したりするグローバル例外ハンドラーに到達するまで、バブルアップさせておく必要があります( s) アプリケーションを適切に終了する前。例外はポケモンとは異なります。すべてを捕まえる必要はありません。対処方法を知っている人だけを捕まえてください。(グローバル例外処理に関する関連資料。 )

  2. 「ファイル/レコード/オブジェクトが見つからない場合をどのように処理しますか」という特定の質問への回答として、答えも比較的簡単です。常に例外を処理します。

    最初にオブジェクトが存在することを確認することは、一見すると良い考えのように思えます。失敗することがわかっていることをしようとしないのは、防御的なプログラミングのように思えます。そして、防御的プログラミングがベスト プラクティスであることは誰もが知っています。

    だから問題は何ですか？競合状態として知られる比較的微妙なもの。オブジェクトにアクセスする前にそのオブジェクトが存在することを確認したからといって、オブジェクトの存在を確認してからアクセスしようとするまでの間にオブジェクトが消える可能性があります。擬似コード:

    if (!File.Exists(myFile))
{
    MessageBox("Sorry buddy, that's a no-go.");
}
else
{
    // Uh-oh! The file got deleted!
    File.Open(myFile);  // fails
}

    もちろん、これは非常に珍しいことだと自分に言い聞かせていることでしょう。2 行のコードを実行する間に、オブジェクトが実際に消える (またはオブジェクトにアクセスできなくなる) 頻度はどれくらいですか? まあ、実際にはそれほどありそうもないことではありません。ファイルがネットワーク ドライブにあり、ネットワーク ケーブルが突然抜かれた場合を考えてみましょう。しかし、それが非常にまれであっても、それが例外と呼ばれる理由です。

    したがって、ここでの適切な解決策は、例外を処理することです。防御的にプログラムしたとしても、競合状態を処理するために例外を処理する必要があるからです。そして、不必要なコードの複製が悪いことであることは誰もが知っています。

于 2013-03-11T12:49:47.210 に答える
1

2 番目のオプションでうまくいっています。コード内に例外が発生する可能性が非常に低い部分がある場合 (発生したとしても)、それらを .xml に含めるべきではありませんtry-catch。
私の目には、例外を処理する「方法」が 1 つしかない場合はほとんどありません。プログラムの誤動作やクラッシュを引き起こす可能性のあるコードの部分を保護することは重要です。
さらに、複数のtry-catch-block を使用してさまざまな例外をキャッチすることも有効です。場合によっては、同等に特徴付けて、それ以上区別したくない例外があります。それでも、他の発生では、まったく予期しない例外があり、少なくとも次を使用して見つけることができますcatch(Exception ex) { ... }

MSDNを少し調べてみると、役立つかもしれません。

于 2013-03-11T12:45:37.013 に答える