0

.NetでCRUD操作を開発するとき（特にデータベースをデータソースとして使用するとき）、try-catchブロックのcatchセクションで使用するための自信のあるアプローチがあるかどうか疑問に思いました。

さて、以下の行についてどう思いますか？

public int Insert(string name, Int32 employeeID, string createDate)
    {
        SqlConnection connection = new SqlConnection();
        connection.ConnectionString = this._ConnectionString;
        try
        {
            SqlCommand command = connection.CreateCommand();
            command.CommandType = CommandType.StoredProcedure;
            command.CommandText = "UnitInsert";
            if (connection.State != ConnectionState.Open)
                connection.Open();
            SqlCommandBuilder.DeriveParameters(command);
            command.Parameters["@Name"].Value = name;
            command.Parameters["@EmployeeID"].Value = employeeID;
            command.Parameters["@CreateDate"].Value = createDate;
            int i = command.ExecuteNonQuery();
            command.Dispose();
            return i;
        }
        catch
        {
            **// how do you "catch" any possible error here?**
            return 0;
            //
        }
        finally
        {
            connection.Close();
            connection.Dispose();
            connection = null;
        }
    }
4

4 に答える 4

3

初心者にはusingステートメントを使用します。

失敗として0を返すことはありません。レコードを正常に更新できないため、0が有効な成功応答コードになります。-1を使用すると、問題が発生したことが明確に示されます。個人的には、予期しないことが起こった場合に備えて、例外をスローしたいと思います。

try
    { 
       using (SqlConnection connection = new SqlConnection())
        {

            connection.Open();         

            using(SqlCommand command = connection.CreateCommand())
            {
                    command.CommandType = CommandType.StoredProcedure;
                    command.CommandText = "UnitInsert";

                    SqlCommandBuilder.DeriveParameters(command);
                    command.Parameters["@Name"].Value = name;
                    command.Parameters["@EmployeeID"].Value = employeeID;
                    command.Parameters["@CreateDate"].Value = createDate;

                    return command.ExecuteNonQuery();
               }

        }
        }
        catch(Exception ex)
        {
          LogException(ex);
           return either -1 or re throw exception.
        }
于 2010-04-29T12:02:01.273 に答える
2

私の意見では、これはあなたがその場で扱うことができないものを捕まえるのに完全に間違った場所です。例外をバブルアップさせ、呼び出し元のアプリケーションに独自のエラー処理を実装させます。ここで例外をキャッチして飲み込むと、インストールされているアプリケーションのデバッグは悪夢のようになります。

あなたが扱えるものを捕まえて、他のすべてを投げるだけです...

于 2010-04-29T12:02:13.643 に答える
0

私はします

catch(Exception ex){
     // log exception here and set return value
}
于 2010-04-29T12:02:25.497 に答える
0

私は、すべての例外を選択した少数の例外に縮小し、実際の例外をとしてネストすることによって、DALのAPIを形式化するのが好きInnerExceptionです。

たとえば、呼び出し元の障害ではないすべてのデータベース例外は1つのタイプの例外をスローし、呼び出し元の障害であるすべてのデータベース例外（行が選択されていない、無効なPK、無効なデータなど）は別のタイプの例外（またはおそらく例外タイプをよりきめ細かく区別することもできます）、データベースに関連しないもの（健全性チェック、NullRefなど）の最後の例外タイプ（処理できない例外（など）を除くOutOfMemoryException）。

そうすれば、DALでスローした例外を簡単にキャッチでき、特定の厄介な詳細はすべてで引き続き利用できますInnerException。

于 2010-04-29T12:08:24.733 に答える