問題タブ [using-statement]

ユーザーkokosは、キーワードに言及することで、 C#の素晴らしい隠し機能の質問に答えました。usingそれについて詳しく説明していただけますか？の用途は何usingですか?

using は例外をキャッチしますか、それともスローしますか? すなわち

ストリームリーダーが例外をスローした場合、呼び出し元の関数がそれを処理できるように、使用またはスローによってキャッチされますか?

UsingC# のブロックの目的は何ですか? ローカル変数とどう違うのですか?

私は using ステートメントを見ているだけです。私はそれが何をするかを常に知っていましたが、今までそれを使用しようとしなかったので、以下のコードを思いつきました:

これは機能しているようですが、SQLサーバーのダウンなどの予期しないエラーをキャッチするために、これをtry catchブロックで囲む必要があると私が知る限り、これには何かポイントがあります。何か不足していますか？

私が現在見ることができる限り、cmdを閉じて破棄するのを止めるだけですが、try catchがまだ必要であるため、コード行が増えます。

私は C# で作業していますが、usingブロックを使用して を実装するオブジェクトを宣言することについてはかなり怠慢IDisposableでした。しかし、いつ滑っているかを簡単に知る方法はありません。Visual Studio はこれをまったく示していないようです (何か足りないのでしょうか?)。何かを宣言するたびにヘルプをチェックして、どのオブジェクトが使い捨てで、どのオブジェクトが使い捨てでないかについて百科事典的な記憶を徐々に構築することになっているのでしょうか? 不必要で、苦痛で、エラーが発生しやすいようです。

これをどのように処理しますか？

編集：

関連する質問のサイドバーを見て、とにかくオブジェクトのファイナライザーによって呼び出されることになっていることを明確にする別の質問を見つけました。Dispose()したがって、自分で呼び出さなくても、最終的には発生するはずです。つまり、使用しなくてもメモリリークは発生しませんusing(これは、私がずっと心配していたことだと思います)。唯一の注意点は、ガベージ コレクターは、オブジェクトが管理されていないものとして保持している余分なメモリの量を知らないため、オブジェクトを収集することによって解放されるメモリの量を正確に把握できないことです。これにより、ガベージ コレクターのパフォーマンスが通常よりも低下します。

要するに、私が逃したとしても、それは世界の終わりではありませんusing. 何かが少なくとも警告を生成することを願っています。

(トピック外: 別の質問にリンクするための特別なマークダウンがないのはなぜですか?)

編集：

わかりました、わかりました、騒ぎ立てるのはやめてください。それは、コールするのが非常に重要な、すべてが発射された劇的なシマリスレベルです。Dispose()

今。それを考えると、なぜそんなに簡単に — 地獄、なぜそれが許されているのでしょう — 間違ったことをするのですか? あなたはそれを正しく行うために最善を尽くさなければなりません。他のすべてのようにそれを行うと、ハルマゲドンが発生します（明らかに）。カプセル化はここまでですよね？

[立ち去る、うんざり]

読み取り/書き込みロックを使用するプロパティがたくさんあります。try finallyまたはusing句のいずれかでそれらを実装できます。

では のtry finally前にロックを取得しtry、 で解放しfinallyます。このusing節では、コンストラクターでロックを取得し、Dispose メソッドで解放するクラスを作成します。

私は多くの場所で読み取り/書き込みロックを使用しているので、より簡潔な方法を探していましたtry finally。ある方法が推奨されない理由、またはある方法が別の方法よりも優れている理由について、いくつかのアイデアを聞きたいと思っています。

方法 1 ( try finally):

方法 2:

マネージ C++ で次の C# コードをどのようにコーディングしますか?

明確化: 管理対象オブジェクト用。

SqlConnection が定義され、次に SqlCommand が定義されている多くの例が、両方とも Using ブロックに存在することを知っています。

私の質問: SqlCommand で直接接続を定義すると、コマンドが破棄されたときに接続が閉じますか?

アプリケーションで特定の名前空間を使用しているかどうかを簡単に判断する方法はありますか。using System.Reflection などの不要な using ステートメントをすべて削除したいのですが、それらのライブラリを使用しているかどうかを判断する方法が必要です。ツールResharperがこれを行うことは知っていますが、これを行うための迅速で汚い無料の方法はありますか?

私は、C# で「正しい」ネットワーク コードを記述する最善の方法について、多くの調査を行ってきました。

C# の "using" ステートメントを使用した多くの例を見てきました。これは良いアプローチだと思いますが、さまざまな式で一貫性のない使用方法を見てきました。

たとえば、次のようなコードがあるとします。

明らかに、このコードは非常に不安定になります。それで、tcpClient を使用するコードを見てきましたが、これは良さそうです。しかし、NetworkStream にもクリーンアップが必要なリソースはありませんか? StreamReader/Writer はどうですか?

ネストされた using ステートメントで 4 つのステートメントすべてをラップする必要がありますか?

もしそうなら、処分する時が来たらどうなりますか？StreamWriter はストリームを閉じず、その結果ソケットを閉じませんか? では、StreamReader、NetworkStream、TcpClient がそれぞれ破棄されるとどうなるでしょうか?

これは別の質問を引き起こします。StreamReader と StreamWriter の両方が同じストリームで構成されている場合、誰がそれを所有しますか? 二人とも自分が所有していると思って、破壊しようとしているのではありませんか? それとも、フレームワークはストリームが既に破棄されていることを認識しており、黙って無視しているのでしょうか?

using ステートメントはチェーンの最後のステートメントにのみ必要なように思えますが、GetStream() で例外がスローされた場合はどうなるでしょうか? その場合、ソケットが適切にクリーンアップされるとは思わないので、これが起こらないようにするために冗長な使用が必要なようです。

例外処理とリソース管理に関する章を含む、.net とできれば c# を使用したネットワーク プログラミングに関する優れた最近の本を知っている人はいますか? または、オンラインの良い記事はありますか？私が見つけることができるすべての本は .NET 1.1 時代 (Microsoft .NET Framework のネットワーク プログラミング、.NET でのネットワーク プログラミングなど) のものであるため、これは適切なリソースが必要なトピックのようです。

編集：

マークの非常に良いコメントが、他の誰かがこれについてコメントするのを止めさせないでください:)

特に非同期の使用に関して、リソース管理に関する本の推奨事項や意見を誰か他の人に聞いてみたいです。