SqlCommand.ExecuteReader() 什么时候会返回 null？
当使用调用 SqlCommand.ExecuteReader() 方法时，ReSharper 告诉我，当我之后使用 SqlDataReader 对象时，可能会出现 NullReference 异常。
因此，使用以下代码：
using (SqlConnection connection = GetConnection())
{
using (SqlCommand cmd = connection.CreateCommand())
{
cmd.CommandText = ; //snip
using (SqlDataReader reader = cmd.ExecuteReader())
{
while (reader.Read())
{
//snip
}
}
}
}
while (reader.Read()) 行带有下划线。
我的问题是 reader 对象什么时候会为空？ 我从来没有遇到过它，文档也没有提到它可能是这样。 我应该检查它是否为空或者可以安全地忽略吗？
为什么 ReSharper 会认为它可能为 null，例如，它允许我使用 SqlCommand，而不建议检查它是否为 null？ 我猜 ExecuteReader 方法上有一个属性。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
这是误报。
反思 SqlDataReader.ExecuteReader，我可以看到读取器返回为 null 的唯一方法是内部 RunExecuteReader 方法为 returnStream 传递“false”，但事实并非如此。
在 SqlDataReader 的深处，a 读取器构造函数总是在某个时刻被调用，因此我非常确定 ExecuteReader 在物理上不可能返回 null。
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.
Resharper 是正确的，它可能会返回 null 。
ExecuteReader() 的特定实现是否不允许冒泡空值并不重要 - 事实上 IDataReader 是一个可以包含（或指向）空值的对象。
IDbCommand的不同实现怎么办？为了正确使用接口，您不需要知道接口的实现内部发生了什么 - 您只需要知道接口，并且现在接口允许 null 作为返回值。
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.
我在其他几个领域也遇到过这个问题。 他们似乎已经对 CLR 各个部分的代码路径进行了分析。 当他们发现可以返回 null 时，他们就会抱怨。
在我抱怨的特定情况下， null 实际上不可能发生。 然而，他们跟踪调用图直到一个在某些情况下可能返回 null 的方法，并且 null 值可能会传播到顶部。
所以，我称其为 ReSharper bug（我之前称其为 CLR bug）。
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).
我已经确定了 ExecuteReader() 可以返回 null 的原因之一。
在我得到空值的情况下，我向客户发送了一个脚本来更新存储过程。 我客户的 Sql Server (2000) 已设置为数据库用户需要执行存储过程的权限。 当他们更新 SP 时，权限被删除并且没有重新分配。 在此实例中，SqlCommand.ExecuteReader() 返回 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.
对我来说它不为空，但在 Powershell 中查看时不会输出任何内容。
当查询没有返回行时就会发生这种情况。
For me it was not null, but would output nothing when viewed in Powershell.
This would happen when the query returned no rows.