Is there a reason to check for null inside multiple using clausule in c#?

Is there a reason to check for null in the last using? Seems to me like it's most likely not gonna be needed?

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:

Should i close reader.Close() and connection.Close() inside the using if i use it like that:开发者_运维百科

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

Is using of close necessary in following example or i can skip those two? sqlWrite.Close(); varConnection.Close();

With regards,

MadBoy

---

No, this is not necessary.

But that follows from the definition of ExecuteReader, it is not related to the using clause. ExecuteReader either returns a (non-null) DataReader object or it throws an exception.
The expresion in the if statement will always be true (if it is reached).

And by leaving out the if and all the superfluous brace-pairs you can make this much easier to read:

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

---

No. Why would you do that? The documentation doesn't suggest that it might be null. What would you do if it was null, anyway? Try it again?

---

Since you are specifically using SqlConnection and SqlCommand - no, there is no reason for this check.

However, the ADO interfaces are so that you can plug in any other DB provider and use them via the ADO base classes (DbConnection, DbCommand etc). It seems that some providers are returning null sometimes (MySQL maybe?), which may be why the programmer inserted this. Or just because ReSharper issues a warning here? These may be reasons for this, even though it is not necessary if the providers used follow the contract.

---

the using statements are not going to check for null for you, so if command.ExecuteReader() can return null you have to check for it explicitly, just like in your code snippet.

EDIT: Looks like in this particular case ExecuteReader() should now return null, so you can avoid it. Please remember that you need it in general case though.

---

Seems like the null check is worth it simply to avoid that slim chance that the object is null. Take a look at my answer to How can I modify a queue collection in a loop?

In the example Queue.Dequeue() should never return a null but it does. It's an extreme case but I don't see why you wouldn't want to avoid an unhandled exception, especially if it's as easy as if (object != null)

For Henk (you can run the code yourself and get similar results):

alt text http://www.ccswe.com/temp/Untitled.png

Either way I was simply stating my opinion that just because the documentation says it will do one thing doesn't mean it always will. Not sure why I got the downvote simply because someone has a different opinion :-)

Edit: Stupid tool tip, either way you can see the processed is 9998065 and the null values encountered is 2264. If there is something fundamentally wrong with my example code I'd be interested in hearing it. I'm gonna back away from this thread now.

---

In this case you should not check reader for null.

But you may use Code Contracts library and use Contract.Assume (or Contract.Assert) to write your assumptions about code. In this case you can use tools for static analysis and easily remove this checks from your release builds.