Есть ли причина для проверки на нулевое значение внутри множественного числа, используя clausule в c #? - PullRequest
Новая
       11

Есть ли причина для проверки на нулевое значение внутри множественного числа, используя clausule в c #?

2 голосов
/ 08 февраля 2010

Есть ли причина проверять ноль при последнем использовании? Мне кажется, что это, скорее всего, не понадобится? 

using (var connection = new SqlConnection(connectionString))
{
using (var command = new SqlCommand(commandString, connection))
{
    using (var reader = command.ExecuteReader())
    {
      if (reader != null) {
         // Use the reader
      }
    }
   }
}

EDIT:

Должен ли я закрыть reader.Close () и connection.Close () внутри использования, если я использую его так: 

            using (var varConnection = Locale.sqlConnectOneTime(Locale.sqlDataConnectionDetailsDZP))
            using (var sqlWrite = new SqlCommand(preparedCommand, varConnection)) {
                 while (sqlWrite.Read()) {
                  //something to do.
                 }
                 sqlWrite.Close();
                 varConnection.Close();
            }




    public static SqlConnection sqlConnectOneTime(string varSqlConnectionDetails) {
        SqlConnection sqlConnection = new SqlConnection(varSqlConnectionDetails);
        sqlConnect(sqlConnection);
        if (sqlConnection.State == ConnectionState.Open) {
            return sqlConnection;
        }
        return null;
    }

Нужно ли использовать close в следующем примере, или я могу пропустить эти два? sqlWrite.Close (); varConnection.Close ();

С уважением,

MadBoy

Ответы [ 6 ]

4 голосов
/ 08 февраля 2010

Нет, это не обязательно.

Но это следует из определения ExecuteReader, оно не связано с предложением using. ExecuteReader либо возвращает (ненулевой) объект DataReader, либо выдает исключение.
Выражение в операторе if всегда будет истинным (если оно достигнуто).

И, опуская if и все лишние парные скобки, вы можете значительно упростить чтение: 

using (var connection = new SqlConnection(connectionString))
using (var command = new SqlCommand(commandString, connection))
using (var reader = command.ExecuteReader())
{
    // Use the reader
}
3 голосов
/ 08 февраля 2010

Нет. Почему ты бы так поступил? Документация не предполагает, что она может быть нулевой. Что бы вы сделали, если бы оно было null, в любом случае? Попробуйте еще раз?

1 голос
/ 08 февраля 2010

Поскольку вы специально используете SqlConnection и SqlCommand - нет, для этой проверки нет никаких оснований.

Однако интерфейсы ADO позволяют подключить любого другого поставщика БД и использовать его через базовые классы ADO (DbConnection, DbCommand и т. Д.). Кажется, что некоторые провайдеры возвращают null иногда ( MySQL, возможно, ?), И, возможно, программист вставил это. Или просто потому, что ReSharper выдает здесь предупреждение ? Это может быть причиной этого, даже если в этом нет необходимости, если используемые поставщики следуют контракту.

1 голос
/ 08 февраля 2010

Похоже, что проверка на ноль стоит того, чтобы просто избежать малой вероятности того, что объект будет нулевым. Посмотрите на мой ответ на Как я могу изменить коллекцию очередей в цикле?

В примере Queue.Dequeue() никогда не должен возвращать ноль, но это так. Это крайний случай, но я не понимаю, почему вы не хотите избегать необработанного исключения, особенно если это так просто, как if (object != null)

Для Хенка (вы можете запустить код самостоятельно и получить аналогичные результаты):

альтернативный текст http://www.ccswe.com/temp/Untitled.png

В любом случае, я просто высказывал свое мнение, что только потому, что в документации сказано, что это будет делать одно, не значит, что так будет всегда. Не уверен, почему я получил отрицательный голос просто потому, что у кого-то другое мнение: -)

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

1 голос
/ 08 февраля 2010

операторы using не будут проверять наличие нуля для вас, поэтому, если command.ExecuteReader () может вернуть значение null, вы должны проверить его явно, как в фрагменте кода.

РЕДАКТИРОВАТЬ: похоже, что в данном конкретном случае ExecuteReader () теперь должен возвращать ноль, так что вы можете избежать этого. Пожалуйста, помните, что вам это нужно в общем случае, хотя.

0 голосов
/ 08 февраля 2010

В этом случае вы не должны проверять читателя на ноль.

Но вы можете использовать библиотеку Code Contracts и использовать Contract.Assume (или Contract.Assert), чтобы написать свои предположения о коде. В этом случае вы можете использовать инструменты для статического анализа и легко удалить эти проверки из ваших сборок релиза.

...