When would SqlCommand.ExecuteReader() return null?

Question

When using calling the SqlCommand.ExecuteReader() method, ReSharper tells me I have a possible NullReference exception when I use the SqlDataReader object afterwards.

So with the following code:

using (SqlConnection connection = GetConnection())
{
    using (SqlCommand cmd = connection.CreateCommand())
    {
        cmd.CommandText = ; //snip

        using (SqlDataReader reader = cmd.ExecuteReader())
        {
            while (reader.Read())
            {
                //snip
            }
        }
    }
}

The while (reader.Read()) line is underlined.

My question is when would the reader object ever be null? I've never come across it and the documentation doesn't mention that it could be. Should I be checking if it's null or is it safe to ignore?

And why would ReSharper think that it could be null, when for example it lets me use the SqlCommand without recommending it be checked for null? I'm guess there's an attribute on the ExecuteReader method.

Answer 1

It's a false positive.

Reflecting on SqlDataReader.ExecuteReader, I can see that the only way the reader is returned as null is if the internal RunExecuteReader method is passed 'false' for returnStream, which it isn't.

In the depths of SqlDataReader, a reader constructor is always called at some point, so I'm pretty sure this is not physically possible for ExecuteReader to return null.

Answer 2

Resharper is correct, it can return null in potential.

It does not matter if a specific implementation for ExecuteReader() will not allow to bubble up a null value - the fact remains that IDataReader is an object which can contain (or point to) null.

• What if in the future you decide to use a different implementation of IDbCommand?
• What if the next update of that IDbCommnd implementation will contain a different flow in the code which will allow to bubble up null?

You do not need to know what happens inside the implementation of an interface in order to use it correctly - you just need to know the interface, and right now the interface allows null as a return value.

Answer 3

I had this issue with them in a couple of other areas. It seems they've done an analysis of the code paths in the various parts of the CLR. When they find that it's conceivable to return null, that's when they complain about it.

In the particular case I complained about, null couldn't actually happen. However, they traced the call graph down to a method which could return null, under some circumstances, and the null value could conceivably propagate to the top.

So, I call it a ReSharper bug (thought I previously called it a CLR bug).

Answer 4

I have determined one reason why ExecuteReader() can return null.

In the case where I was getting a null, I had sent my client a script to update a stored procedure. My client's Sql Server (2000) is set up so that DB users need a permission to execute a stored procedure. When they updated the SP the permission was removed and not re-assigned. In this instance the SqlCommand.ExecuteReader() returned a null.

Re-assigning the permission fixed this.

Answer 5

I had an issue where I queried .dbo.sysfiles for logfiles and got a null in return. I had my client connect as SYSTEM user who was sysadmin, not sure what happened...