5

私はそのようなコードを少し持っています

try
{
    result.FirstName = nodes[myIdx].Attributes["ows_FirstName"].Value;
} catch { }

この呼び出しを呼び出す前に、探している属性が存在するかどうかはわかりません（Good ol sharepoint）。

結果として、私が作成しようとしているコードを書くことができる唯一の直線的な方法は、それ自体です。

try
{
    result.FirstName = nodes[myIdx].Attributes["ows_FirstName"].Value;
} catch { }
try
{
    result.LastName = nodes[myIdx].Attributes["ows_LastName"].Value;
} catch { }

....

今、私はこのコードのcatchセクションを使用せず、完全に冗長な大量の行になってしまいます。

なぜ私はできなかったのですか

try { result.FirstName = nodes[myIdx].Attributes["ows_FirstName"].Value; }

では、処理されていない場合でも、なぜcatchブロックを明示的に宣言する必要があるのでしょうか。確かに正当な理由があると思いますが、うまくいきません。

編集：誰もが例外を飲み込むのは悪いことだと私に向かって出発する前に、何とか何とか何とか。私たち（および私）はすべてこれらの議論を知っていますが、この（そして多くの）現実世界のシナリオでは、例外について例外的なことは何もなく、行動を修正するために私ができること（またはする必要があること）はありません。

4

10 に答える 10

6

例外を飲み込みたい場合（catchそれは何もしません）、明示的にそうする必要があります。

これは通常、不適切な方法であるため、構文上のショートカットを提供する理由はありません。通常、次のいずれかを行う必要があります。

  1. 何らかの方法で例外を処理します。これは次のことを意味するかもしれません：
a。リトライ
b。より意味のあるメッセージでそれを再スローします（内部例外を保持します）。
c。別の方法でやってください。
d。ログに記録します（ただし、ログと再スローの方が良い場合があります）。
e。他の

2.泡立てるだけです（試さない、または試して/最後に）。

于 2012-03-15T02:21:08.433 に答える
6

それらは冗長ではありません-それらは特定の目的を持っています。デフォルトでは、catchブロックがないと、呼び出し元のメソッドに例外が再スローされます。空のcatchブロックは基本的に例外を「飲み込み」、例外がスローされたかどうかに気付かずにプログラムを続行させます。一般的に悪い習慣です。

例外について例外的なことは何もありません

この場合、 1つのタイプの例外が「例外的」ではないことは事実かもしれませんが、発生する可能性のある例外はそれだけではありません。その例外を処理し、他の例外に適切に対処する必要があります。

例えば ​​-

nodesnullの場合はどうなりますか？配列myIdxの境界外にある場合はどうなりますか？nodesこれらの条件はいずれも例外的であり、具体的に処理するか、呼び出し側プログラムに処理させて適切に動作させる必要があります。

[あります]動作を修正するために私ができること（またはする必要があること）は何もありません

修正できない場合もありますが、注意が必要な場合があります。その場合、プログラムの動作はどのように異なりますか？メッセージを記録しますか？警告を出しますか？デフォルト値を設定しますか？何もしないことは適切な答えかもしれませんが、考えられる例外に対する適切な応答ではない可能性が非常に高いです。

于 2012-03-15T02:25:10.743 に答える
4

アイテムがチェックされていないかどうかを確認してみませんnullか？

if(nodes[myIdx].Attributes != null &&
   nodes[myIdx].Attributes["ows_FirstName"] != null) {
    /* ... your code ... */
}

または：

if(nodes[myIdx].Attributes != null) {
   if(nodes[myIdx].Attributes["ows_FirstName"] != null) {
       /* ... your code ... */
   }
   if(nodes[myIdx].Attributes["ows_LastName"] != null) {
       /* ... your code ... */
   }
}
于 2012-03-15T02:22:58.123 に答える
3

その属性が存在するかどうかを確認する別の方法が必要です。機能的な目的で例外処理を使用しないでください。次のようにコーディングします。

try
{
    newstring = oldString.ToString();
}
catch{}

あなたがすべきことは：

if(oldString != null)
{
    newstring = oldString;
}

try catchは、「例外」という名前の処理を行うためのものであることを忘れないでください

于 2012-03-15T02:24:09.477 に答える
2

理由はおそらく、例外を処理できない場合に例外をキャッチするべきではないためです。try対応するものなしであなたを許可することcatchは、最悪の慣行を可能にする以外に何もしません。

参照している特定のコードについては、インデクサーにアクセスする前にnullチェックを実行できませんか？

于 2012-03-15T02:22:17.577 に答える
1

try / catchブロックは、アプリケーションでスローされた例外をキャッチして処理するために明示的に設計されました。

単に例外を飲み込むことは、通常は悪い考えであり（例外をログに記録しているだけの場合でも）、明示的に実行する必要があります。

于 2012-03-15T02:21:35.657 に答える
1

これは言語構文の一部です。try少なくとも1つcatch、またはを欠くことはできませんfinally。スタンドアロンはなく、、、、tryのみtry-catchです。try-finallytry-catch-finally

try例外（）をわざわざ処理しない場合catch、または少なくとも、何が起こったかに関係なく、後続のコードが常に実行されるようにする場合（それは）、一部のコードには意味がありませんfinally。

于 2012-03-15T02:22:55.750 に答える
1

これは、この質問でほぼ回答されています：C＃：すべての例外をキャッチする必要があります

基本的に、あなたがそれを捕まえているならば、あなたはそれで何かをするべきです、さもなければそれを捕まえないでください。あなたの場合、属性値が最初に存在するかどうかを確認できないのはなぜですか？

于 2012-03-15T02:23:34.967 に答える
1

SharePoint Webサービスの1つを使用しているように見えるので、戻り値のタイプはある種のXmlElementですか？属性が存在するかどうかを確認する方法があると確信しています。これは、例外をスローするよりも安価です。

また、チェックとデータ取得をカプセル化するヘルパーメソッドが必要です。

于 2012-03-15T02:25:36.983 に答える
0

空のキャッチブロックがあってはなりません。それは貧弱なプログラミング慣行です。

クラシックASPを思い出させますOn Error Resume Next

于 2012-03-15T02:24:40.680 に答える