When using calling the SqlCommand.ExecuteReader()
method, ReSharper tells me I have a possible NullReference exception when I use the SqlDataReader object after
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).
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.
IDbCommand
?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.
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...
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.
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.