問題タブ [try-finally]

このWeb ページに書かれている内容に基づいて、私の理解が正しければ、usingステートメントは のように機能するため、ステートメントで例外が発生してもプログラムがクラッシュしtry/finallyないと誤って予想するかもしれません。using

ただし、DownloadString次の例に示すメソッドが をスローするWebExceptionと、プログラムがクラッシュします。

usingステートメントは のようには機能せずtry/catch/finally、実際には例外は処理されないため、これは正常です。usingしかし、私はその声明の目的が何であるか疑問に思います。

更新...以下の回答に基づいて、次の考慮事項を追加します。基本的に、例外を処理する必要がある場合、考えられる解決策は次のとおりです。

1. ステートメントをブロックusing内に配置します。try/catch
2. ブロックDonwloadString内にメソッドのみを配置します。try/catch
3. 次のコード サンプルのように、try/catch/finally ブロックを手動で記述します。

3 番目のソリューションのサンプル コード。

DbContext を渡す場合と渡さない場合があるこのメソッドがあります。

私は 2 つの三項操作を行っています。1 つは廃棄を行う必要があるかどうかを判断するため、もう 1 つは新しい dbContext を作成する必要があるかどうかを判断するためです。

質問: 両方の 3 項演算はまったく同じ条件です。自分と変数を 1 つの演算で(db == null)設定する方法はありますか?disposedb

ある時点で尋ねられたに違いないと思うので、この質問を探してみましたが、これは私が見つけることができる最も近いものでしたRemove Top-Level Container on Runtime。

私の質問は、破棄が で行われ、実行コードが で行われた場合、そのダイアログJDialogを呼び出した後、 でコードを実行しても安全ですか?dispose()tryfinally

私が求めていることを示す例を次に示します。

dispose()プロセスとブロックについて私が知っていることからfinally、素晴らしいアイデアではないにしても、うまくいくはずだと思います。実際、上記のコードを実行すると、正常に印刷されます。

try/の間で GC が開始され、finally何らかの問題が発生する可能性はありますか?