2

このような：

Cursor.Current = Cursors.WaitCursor;
try {
  . . .
} finally {
    Cursor.Current = Cursors.Default;
}

またはこれ：

try {
  Cursor.Current = Cursors.WaitCursor;
  . . .
} finally {
    Cursor.Current = Cursors.Default;
}

？

4

5 に答える 5

3

Cursor.Current事前定義されたカーソルをに割り当てても例外がスローされないため、2つのアプローチに違いはありません。リソースファイルからカーソルをロードしている場合、その動作は実際には例外をスローする可能性があります（たとえば、指定されたリソースが見つからない場合）。

重要なのはfinally、両方の例で行う、ブロック内の目的の状態にカーソルを設定することです。

于 2012-07-02T18:25:55.977 に答える
1

自問してみてください、その行の結果は例外をスローしますか？この単純なケースでは、例外がスローされた場合に限り、finally句で通常の状態に戻るかどうかは問題ではありません。個人的にはCursor.Current = Cursors.WaitCursor、例外がスローされないため、その行はスローしません（単に割り当てを行っているだけです）。

于 2012-07-02T18:25:55.650 に答える
1

例外をスローしない限り、中に入れてもかまいません。

例外がスローされる場合は、ブロックでスローされる特定のタイプの例外をcatch処理するか、プログラムがブロックを使用して終了する前に、最終的な調整とリソースの割り当て解除を処理する必要がありますfinally。

ここにあなたが読むためのいくつかの良い情報があります：http： //msdn.microsoft.com/en-us/library/ms173160.aspx

于 2012-07-02T18:26:57.537 に答える
1

最初のカーソル割り当てをtryブロック内に置いても害はありません。他の人が指摘しているように、割り当てが例外をスローしないことが確実にわかっている場合は、厳密にtryブロック内にある必要はありません。よくわからない場合は、tryブロック内に配置することをお勧めします。

一般的なコーディングパターンとして、ステートメントが例外をスローできるかどうかわからない場合は、それをtryブロック内に配置します。本当に必要なときにtryブロックの外側に配置するよりも、tryブロックの内側に配置して、間違っていると推測/推測するよりも、必要ない方がよいでしょう。

于 2012-07-02T18:35:47.147 に答える
0

試してみる前にカーソルセッターを置きます。その理由は、try / finalのアプローチは、try-block内のコードが例外をスローした場合にカーソルに影響を与えないようにするためです。ただし、Cursorプロパティ自体からのエラーを防止しようとしているわけではありません。そこにエラーがある場合は、個別に処理するか、未処理の例外が発生してアプリが破棄されるようにする必要があります。最後に必要なのは、カーソルを設定して例外をスローし、finallyブロックで再度設定しようとしたときに別の例外を取得することです。クラッシュレポートには2番目の例外しか表示されず、おそらく間違ったものが送信されます。あなたがそれをデバッグするために行くときのパス、そしてあなたの多くの時間を無駄にします。

于 2012-07-03T07:16:59.140 に答える