3

そのまま、コードのエラー防止を試みたところ、非常に乱雑に見えてしまいました。

特定の種類のファイルを読み取る機能を設定しています。問題が発生した場合は関数が false を返し、すべてが機能した場合は true を返します。すべてを構造化する方法を理解するのに苦労しています。

ファイル ストリームを開こうとする最初の try-catch ブロックがあります。その後、ファイルサイズや特定のオフセットでの値など、読み取りプロセス中に行う他の特定のチェックがあります。私が設定した方法は、if else ステートメントを使用することでした。そのような：

if(condition){

}
else{
    MessageBox.Show("There was an error");
    br.Dispose();
    fs.Dispose();
    return false;
}

...br はバイナリ リーダーであり、fs はファイル ストリームです。このようなブロックがたくさんあり、同じことを何度も書くのは悪い習慣のようです。最初に頭に浮かぶのは、すべてを try-catch ステートメントでラップし、if else ブロックを使用する代わりに例外をスローすることです。try-catch ステートメントについて読んだとき、それらを持っているのは良いことですが、すべてをそれらでラップするわけではないことを覚えています。正直なところ、エラーが発生した場合にのみ効果があるため、すべてを try catch ステートメントでラップするのが悪い習慣である理由をまだ完全には理解していません。

また、バイナリ リーダーとファイル ストリームを閉じる必要がありますか? それらを処分せずに使用する方法はありますか？

4

5 に答える 5

5

usingキーワードを活用してみてはいかがでしょうか。IDisposableこれは、try - finally ブロックでの使用をラップします。

bool success = true;

using(var fs = new FileStream(fileName, FileMode.Create)))
using(var br = new BinaryReader(fs))
{
  // do something
  success = result;
}

return success;

ネストされた using ブロックにより、ファイルストリームとバイナリ リーダーの両方が常に適切に閉じられ、破棄されます。

MSDN で使用について詳しく読むことができます。IDisposable明示的な例外処理の必要性を排除して、少しきれいに使用できます。

あなたの声明について：

try-catch ステートメントについて読んだとき、それらを持っているのは良いことですが、すべてをそれらでラップするわけではないことを覚えています。

私は常に、特定のコード ブロック内の例外を処理して回復できない場合は、それをキャッチしようとしないという単純なルールを使用しています。例外をキャッチする方が理にかなっているポイントまで、例外がスタックを「バブルアップ」できるようにします。このアプローチでは、多くの try-catch ブロックを追加する必要がないことがわかります。サービス (ファイルシステム、ネットワークなど...) との統合の時点でそれらを使用する傾向がありますが、ビジネス ロジックはほとんど常に例外処理メカニズムがありません。

于 2012-01-01T08:27:57.520 に答える
1

using使い捨てオブジェクトにキーワードを使用するだけです。usingキーワードのブロック内で、throw例外returnを処理したり、破棄について心配する必要がなくなります。それはあなたのために自動的に起こります。

try-catchブロックは、より良い代替手段であるブロックが存在するという理由だけで、あまり良い考えではありませんtry-finally。しかし、usingキーワードは本質的にtry-finallyブロックに展開され、オブジェクトの破棄を処理するため、さらに優れています。

ファイル ストリームを閉じると、バイナリ リーダーも閉じられます。それらを処分せずに使用したいのはなぜですか？それらを破棄する方が良いです。経由で破棄するusingのが最善の方法です。

于 2012-01-01T08:28:00.297 に答える
0

ファイルストリームが確実に破棄されるようにする最善の方法は、その使用法を次のusingブロックでラップすることだと思います

using (FileStream)
{
    ....
}
于 2012-01-01T08:28:56.987 に答える
0

はい、それは悪い習慣です。

問題が発生したかどうかを示すブール値を返す代わりに、例外をスローする必要があります。例：

if (headNotValid)
   throw new Exception("Header was not valid");

場合によっては、新しい例外クラスを作成することをお勧めします。

から継承するクラスを操作する場合は、ディレクティブIDisposableを使用する必要があります。using

using (var stream = new FileStream(filename))
{
}

usingこれにより、ブロック内で例外がスローされた場合でも、ストリームが破棄されることが保証されます。

要約すると、私は次のようなものを好むでしょう：

private void string ParseFile(string filename)
{
     using (var stream = new FileStream(filename))
     {
           if (somethingNotValid)
              throw new Exception(...);

           return ...;
     }
}

そしてあなたのメインで：

{
     try
     {
          var value = ParseFile(filename);
     }
     catch (Exception)
     {
          Console.WriteLine(..);
     }
}
于 2012-01-01T08:31:01.620 に答える
0

usingキーワードを使用します。次のように書き換えることusingができます。

public static int CountCars()
{
    SqlConnection conn = new SqlConnection(connectionString);
    try
    {
      SqlCommand cmd = conn.CreateCommand();
      conn.Open();
      try
      {
        cmd.CommandText = "SELECT COUNT(1) FROM Carsd";

        return (int)cmd.ExecuteScalar();
      }
      finally
      {
        if(cmd != null)
          cmd.Dispose();
      }
    }
    finally
    {
      if(cmd != null)
        conn.Dispose();
    }
}

これに：

public static int CountCars()
{
    using(SqlConnection conn = new SqlConnection(connectionString))
    using(SqlCommand cmd = conn.CreateCommand())
    {
        conn.Open();
        cmd.CommandText = "SELECT COUNT(1) FROM Carsd";

        return (int)cmd.ExecuteScalar();
    }

}

どちらのコード スニペットも、コンパイル時にまったく同じ IL コードを生成します。例はhttp://coding.abel.nu/2011/12/idisposable-and-using-in-c/からのもので、 と の使用について詳しく書いていIDisposableます。

于 2012-01-01T08:55:53.300 に答える