キャッチブロックを使用して戻り値が正しくない

これは愚かな質問かもしれませんが、私はtry/catchブロックを使用することのパフォーマンスに興味があります。キャッチブロックを使用して戻り値が正しくない

私は、DataGridCellのバックグラウンドプロパティにコンバーターを割り当てるDataGridを持っています。コンバーターでは、今年のデータの価値を昨年のデータと比較します。今年のデータが3％を超える場合、私は緑の背景を返します。それが> 0％で< 3％なら、私は黄色を返します。それは< 0％だ場合と、私は赤を返す：

string x = values[0].ToString().Replace("$", "").Replace(",", ""); //This year's number 
string y = values[1].ToString().Replace("$", "").Replace(",", ""); //Last year's 

result = (((float.Parse(x) * 100)/float.Parse(y)) - 1) * 100; 

if (result >= 3) 
    return Brushes.LimeGreen; 
else if (result >= 0) 
    return Brushes.Yellow; 
else 
    return Brushes.Red;

しかし、いくつかのケースでは、セルは、昨年の値を持ちません。あなたが推測できるように、0（またはCellが空のときにコンバーターが受け取ると思われるテキスト）で割ることはかなり悪い考えであり、例外がスローされます。だから、私はこれに対処する最も簡単な方法は判断しました：

だから、

try 
{ 
    result = (((float.Parse(x) * 100)/float.Parse(y)) - 1) * 100; 
} 
catch 
{ 
    return Brushes.DarkOrange; 
}

例外がスローされた場合（と比較する値がないことによって）、オレンジを返し、一日を呼び出します。

現在、私はそれが1行のデータにしか起こらないと予測することができるので、約10個のセルしか捕まえていません（編集：はい、私はオレンジ色を返すことをお勧めします）。しかし、未来が進むにつれて、それがより多く起こる可能性があります。

try/catchブロックは、これを処理するための最も簡単で迅速な方法です（私が知る限り）。それは明らかに私がエラーを知っているので、明らかに唯一の方法ではありませんので、try/catchブロックを使用するのは悪い考えですか？悪い考えでは、何度も何度も繰り返されるのでパフォーマンスが低下します。？エラーが何であるかを知っているので、私はそれをプリエンプトするか、try/catchブロックをうまく使っていますか？

出典

2012-03-09 Christopher Jones

これは非常に悪い考えです。 .Net例外処理のベストプラクティスに関するGoogleの記事例外の実行について心配するには、赤いライトと警告サイレンが点滅するように設定する必要があります。 – asawyer

代わりにTryParseを使用してください。 – ken2k

これは悪い考えです。それは例外的な状況ではないので、そのように扱わないでください。あなたがパフォーマンスと例外処理について心配しているという事実は、間違ったことをしているという匂いです。これを処理する本当に簡単な方法があるので、なぜ例外処理を使用してそれを処理すると思ったのかわかりません。

はい、あなたのパフォーマンスに影響しますが、ここではそれを考慮する必要はありません。あなたの心配は、このロジックを書くための最も明白な方法でなければならず、例外を使うことは明らかに方法ではありません。 - 期待されていない場合、一般的には

double value; 
if(!Float.TryParse(y, out value) || value == 0f) { 
    return Brushes.DarkOrange; 
} 
else { 
    double result = (((float.Parse(x) * 100)/value) - 1) * 100; 
    if (result >= 3) { 
     return Brushes.LimeGreen; 
    } 
    else if (result >= 0) { 
     return Brushes.Yellow; 
    } 
    else { 
     return Brushes.Red; 
    } 
}

出典

2012-03-09 16:16:42 jason

この問題を解決する方法は問題ではありませんでしたが、試しにキャッチするとパフォーマンスが低下します。 – Quickhorn

ああ、私はこれをすることができることを知っている;私は正直なところ、さまざまなことをやっていたので、問題を解決するためにtry/catchをすばやくハッキングしました。今私はそれを取り戻すつもりです、私はちょうどtry/catchの使い方に興味があったので、投稿しました。私が言ったように、私はこれが私の問題を解決する唯一の方法ではないことをよく承知しています。また、私は問題があると宣言しません。 –

@クイックホーン：そうです、詳しく教えてください。これはひどい考えです。それは例外的な状況ではないので、それを処理するのは悪い方法です。パフォーマンスと例外処理について心配すると、何かが本当に間違っているという匂いがします。私の何？"質問に答える簡潔な方法です：はい、これは悪い考えです。 – jason

、例外は本当に例外的な場合に使用する必要があります。ここでは

は簡単な方法ということです。このような状況では、前年がない可能性があることを十分に認識しているので、単純なif()チェックを使用してデフォルト値を返すことをお勧めします。

パフォーマンスに関する質問に答えるには、Microsoft says「例外をスローするとパフォーマンスに悪影響を与える可能性があります。

出典

2012-03-09 16:17:44 goric

if、tryparse文、try catchが高速になるかどうかを知るには、c＃の複雑さに慣れていません。私があなたに提供できることは、コールについて考える考えです。

同じプロセスの実装と同じように単純なパフォーマンスを心配している場合は、コール数も考慮してください。 1つの番号が0の場合はすべての番号をチェックするか、1つの番号ごとにtry-parseを呼び出すと、失敗した繰り返しだけでなく、その呼び出しがすべての繰り返しに追加されます。この実装がうまくいく場合は、失敗したときにcatchブロックに入るだけで良いアプローチです。

多くのプログラムでは、この種の実装は機能しません。これは、catchブロックで追加の処理を行うためです。これらのプログラムの場合は、0をチェックするか、tryparseを実行します。あなたが戻ってきているので、これは簡単に読めるコードのためのものだと思います。

出典

2012-03-09 16:20:23 Quickhorn

catchステートメントは、例外を捕捉するためにのみ使用する必要があります。プログラムフローを変更するのではなく、あなたの質問に答えるために、はい、これは悪い考えです。そして、新しい例外オブジェクトが作成され、javaがイベントの一部のロギングを行う可能性があるので、それが実行可能であるとは想像できません。

出典

2012-03-09 16:20:54 steelshark

JavaではなくC＃ですが、アプリケーションの仕様に応じて同じ自動ログが適用される可能性があります。興味深い; – asawyer