.Net: Какой у вас уверенный подход в разделе «Catch» блока try-catch, при разработке операций CRUD?

Question

Мне было интересно, будет ли какой-нибудь уверенный подход для использования в секции catch блока try-catch при разработке операций CRUD (особенно, когда вы используете базу данных в качестве источника данных) в .Net?

хорошо, что вы думаете о нижних строках?

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;
        }
    }

Answer 1

Я бы использовал оператор использования для начинающих.

Я бы не вернул 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.
        }

Answer 2

По-моему, это совершенно не то место, где можно ловить то, с чем вы не можете справиться тут же. Пусть возникнет исключительная ситуация, и вызывающее приложение реализует свою собственную обработку ошибок. Если вы поймаете и проглотите исключение здесь, ваша отладка для установленных приложений будет кошмарной.

Только когда-нибудь поймать то, что вы можете справиться и бросить все остальное ...

Answer 3

Мне нравится формализовать API моего DAL, заключив все исключения в несколько избранных и вложив фактическое исключение как InnerException.

Например, все исключения базы данных, которые не являются ошибкой вызывающих абонентов, будут вызывать один тип исключения, все исключения базы данных, которые являются ошибкой вызывающих абонентов (например, не выбраны строки, недопустимый PK, недействительные данные), будут вызывать исключение другого типа (или, возможно, даже имеет более тонкое различие между типами исключений) и один последний тип исключений для вещей, которые не связаны с базой данных (проверки работоспособности, NullRef и т. д.), за исключением исключений, которые я не могу обработать (таких как OutOfMemoryException).

Таким образом, легко поймать исключения, которые я добавляю в мой DAL, и все подробные подробности кровавых данных все еще доступны в InnerException.

Answer 4

Я бы сделал

catch(Exception ex){
     // log exception here and set return value
}