未将对象引用设置到对象的实例 (System.NullReferenceException)
更新时间：2012年03月30日 23:02:35 作者：
System.NullReferenceException：未将对象引用设置到对象的实例，这是一个新鸟，中鸟，老鸟都避不开的错误
下面基础的解释一下这错误：
1：本质上的错误：
object a;//a是Null对象
protected void Page_Load(object sender, EventArgs e)
{
a.ToString();//调用一个Null对象的方法
}
当然啦！结果就如下图了：
2：通常性的错误：
示例1：一个过滤某些字符的函数：
public static string FilterValue(string value)
{
string[] filterChar = new string[] { "\'", ",", ">", "<", "=", ";", "\"", "--" };
for (int i = 0; i < filterChar.Length; i++)
{
value = value.Replace(filterChar[i], "");
}
return value.Trim(' ');
}
这个函数比如容易看的出：如果value传进来为Null的时候，就等于Null.Replace被调用，就出现了上面的错误。
因此，通常的，在函数的首行，都会对value进行：if(!string.IsNullOrEmpty(value)) 一下。
示例2：再举一下通用性的调用错误，绑定，Eval("字段") ，这个方法比较常见，某些情况要转字符串比较，这里示例一下：
<%# Eval("字段").ToString()=="1"?"Yes":"No" %>
当Eval("字段")为Null时，一个Null.ToString()，必然也会出现上面的错误，那什么情况出现？
1：字段的值为Null
2：空数据行，就是你表一行数据都没有，全是Null。
复制代码
所以预防性的写法是：
<%# Convert.ToString(Eval("字段"))=="1"?"Yes":"No" %
好了，看到本文的不管懂的还是不懂的，现在都应该懂了，如果你非要说你不懂，我得赞扬你智商高，下面有智商介绍，别放过。
见到这异常：就是一个Null的对象调用了方法（属性或其它成员）变成Null.XXX引发的。
当然啦，出现这种异常的场景，那可是万万千，数也数不完，但本质是一样的。
个人观点认为，在三只鸟中发生此错误的原因各不同，基本如下：
新鸟：不知道这个错误，或见这错误的次数太少，所以代码基本防都不防，模仿式，大量的函数都潜伏这种错误杀手。
个人猜测：新鸟写的代码，都不加判断的原因可能：
其一：是他们不知这种情况，刚学习，经验不足，未有处理这种异常的经验。
其二：推测是他们高调的认为：多一个Null的判断，会使得性能下降，他们追求高性能，因此，基本上，不加。
中鸟：知道这个错误，只是考虑的不多，心不够细，人不够稳，写代码基本会加，但普遍不加。
中鸟比新鸟吃的虫，肯定多，所以出现这种情况，原因当然不一样了啦。
个人猜测：中鸟写的代码，出现Null引用的原因可能是：
其一：没有养成思维习惯，在加班的压力下，写个函数都是刷刷的就出来了，偶尔会加，普遍不加，加还是不加，等错误出来了再加。
其二：中鸟这时期处于高性能研发性时期，最喜欢的和别人讨论性能问题，特别是当for的次数达到百万级别时，当性能从0.03秒下降到0.01秒时，会为整整提高3倍的性能而欢乎，并认为这是一个重量级的发现，然后推荐推荐给后来者，并BS一些不这么写的新手或同级的鸟。
同理：一个函数加一个null判断，得上升到百万次的调用级别的高度考虑，如果这判断被调用百万次，那性能不是大大的损失？
如果加2个判断，那就是2*百万次的调用，那就是相当大的性能损失，这怎么可以接受的呢？
所以，能不加就不加，加不加，等错误出来了再加。
其三：太懒了，这个本人是这么理解的说：
大伙都知道，中鸟写代码，基本都属于面向对象型的了，那就是天天和对象搞在一块的了，每个对象都要搞来搞去，再多的精也伤不起！
好吧，一个函数传一个参数，给你加一个判断，代码也不多，不算大括号就两行。
可是中鸟基本上写的函数的参数，偏偏三四五六七八九十个，这下让人纠结了：
加吧，一想，工作量太大了，而且这性能感觉不高；
不加吧，好像也没什么问题，这么一想啊，眼前阔然开朗，好，加不加，错误出来了再加。
还有的，不仅是参数的判断要折腾，函数内部产生的对象，也要搞一搞，太多对象要考虑。
光靠精力与考虑，加点人之常情，所以大多数情况是发生在：加不加，错误出来了再加！
老鸟：对这错误太熟悉，心也够细，写代码潜意识会主动加防，但百密一疏，该来的还是会来，躲过初一，躲不过十五。
老鸟吃的虫就更多了，而且老鸟们身经百战之后，觉得系统稳定，才是幸福。
个人猜测：老鸟写的代码，出现Null引用的原因可能是：
其一：代码写多了，基本上都靠潜意识反应，就是说潜能发挥了，再白点就是习惯性思维。
所以基本上都不会怎么犯这错误，但是光靠潜意识，基本都能挡住，基本之外的，还得靠正常思维。
老鸟通常精力不太好，偶尔会走神，一走神，就漏了一个，再一走神，又漏了一个，再一走神，被神招唤了，太平间多了一位客人。
所以我写代码，尽量不走神，免的被招唤，但偶尔也会漏。
其二：是假老鸟，老鸟是装的，其实还是中鸟，硬要装，不过会装，说明智商高。
社会的法则表明，生存的越好的，装的程度越高，越会装，生活就越好，装到最高境界，那就是装孙子。
孙子是一名历史人物：会三十六计，装孙子的说明智商真的很高，没里绝对没有鄙视之意，因为三十六计有时候我也在学，只是智商一直上不去，所以境界一直上不去。
下面再补充一下，个人对中老鸟的看法，以下观点仅为作者扮演的个人的臆测观点，和作者本人无关：
中鸟何以追求性能？
臆测：因为他们通常只接触到系统的一部分，缺少整个系统体系的了解，所以他们希望在他们负责的那一个区域里，写出性能至上的代码，这能说有错吗？
没错，而且理论上就应该这么干！但是，稳定不足，如果能写出又稳定又高性能的代码，有多好呢！
重点还是讲老鸟：老鸟何以不太关注性能，而求稳定？
其实，老鸟并不是不关注性能，而是他关注的是：
一：稳定，这个很重要：
因为系统一上线：
首先：得对老板负责啊，你说是不是？
然后：如果这个产品是要给客户演示的，那得对客户负责啊，你说是不是？
再者：如果这个产品要上线运营，那得对访客负责啊，你说是不是？
所以，不管你系统怎么样，首先，保证稳定，至少给老板或客户或访客演示或操作的时候，你不能出错，至于慢点不慢点，那个好商量，好商量。
二：整体性能大于局部性能
I：这个就很明显了，你一个算法写的很好，可是其它选手数据库写的差，一访问，很慢，这怎么说的过去。
II：所以要保证整体访问性能差不多先，然后再进行局部优化，这多符合中国人当前的优化思维啊。
III：再说了，每个人局部性能都最大化了，一访问，还是慢，找不到着优化的地方，这可是要出事的：老板得出血买硬件了。
IV：还有，整体上加了缓存+静态化html后，你会发现，局域的最大优化代码，基本都派不上用场了，因为直接就是访问+返回，
至于您那最大化性能的逻辑代码，那是千年走一回了。
当然了，个人对此观点是很负责的，绝对没有任何轻视局部性能最大化的意思，相反还得鼓励大伙局部性能最大化，努力写出最优代码：
一来：这是每个码农往上走必经的阶段，跳过不是件好事。
二来：多让老板出下血，可以平衡下员工不满的心情：你让我加班，我就让你出血，多好呢。
重大说明：
本篇文章绝大多数观点为作者扮演的个人的臆测观点，和本人无关，本人认为，以上观点有些片面，可能与客观事实不符。
请各位看客看在周末的份上，少一份偏激，多一份激动，开X吧！
本视频到此为止，欢迎收看，下次再会，谢谢！
PS：最近顺路折腾了下 CYQ.Data V4.5离线帮助文档，很快发布，敬请关注。
1：本质上的错误：
复制代码 代码如下:
object a;//a是Null对象
protected void Page_Load(object sender, EventArgs e)
{
a.ToString();//调用一个Null对象的方法
}
当然啦！结果就如下图了：
2：通常性的错误：
示例1：一个过滤某些字符的函数：
复制代码 代码如下:
public static string FilterValue(string value)
{
string[] filterChar = new string[] { "\'", ",", ">", "<", "=", ";", "\"", "--" };
for (int i = 0; i < filterChar.Length; i++)
{
value = value.Replace(filterChar[i], "");
}
return value.Trim(' ');
}
这个函数比如容易看的出：如果value传进来为Null的时候，就等于Null.Replace被调用，就出现了上面的错误。
因此，通常的，在函数的首行，都会对value进行：if(!string.IsNullOrEmpty(value)) 一下。
示例2：再举一下通用性的调用错误，绑定，Eval("字段") ，这个方法比较常见，某些情况要转字符串比较，这里示例一下：
<%# Eval("字段").ToString()=="1"?"Yes":"No" %>
当Eval("字段")为Null时，一个Null.ToString()，必然也会出现上面的错误，那什么情况出现？
1：字段的值为Null
2：空数据行，就是你表一行数据都没有，全是Null。
复制代码
所以预防性的写法是：
<%# Convert.ToString(Eval("字段"))=="1"?"Yes":"No" %
好了，看到本文的不管懂的还是不懂的，现在都应该懂了，如果你非要说你不懂，我得赞扬你智商高，下面有智商介绍，别放过。
见到这异常：就是一个Null的对象调用了方法（属性或其它成员）变成Null.XXX引发的。
当然啦，出现这种异常的场景，那可是万万千，数也数不完，但本质是一样的。
个人观点认为，在三只鸟中发生此错误的原因各不同，基本如下：
复制代码 代码如下:
新鸟：不知道这个错误，或见这错误的次数太少，所以代码基本防都不防，模仿式，大量的函数都潜伏这种错误杀手。
个人猜测：新鸟写的代码，都不加判断的原因可能：
其一：是他们不知这种情况，刚学习，经验不足，未有处理这种异常的经验。
其二：推测是他们高调的认为：多一个Null的判断，会使得性能下降，他们追求高性能，因此，基本上，不加。
中鸟：知道这个错误，只是考虑的不多，心不够细，人不够稳，写代码基本会加，但普遍不加。
中鸟比新鸟吃的虫，肯定多，所以出现这种情况，原因当然不一样了啦。
个人猜测：中鸟写的代码，出现Null引用的原因可能是：
复制代码 代码如下:
其一：没有养成思维习惯，在加班的压力下，写个函数都是刷刷的就出来了，偶尔会加，普遍不加，加还是不加，等错误出来了再加。
其二：中鸟这时期处于高性能研发性时期，最喜欢的和别人讨论性能问题，特别是当for的次数达到百万级别时，当性能从0.03秒下降到0.01秒时，会为整整提高3倍的性能而欢乎，并认为这是一个重量级的发现，然后推荐推荐给后来者，并BS一些不这么写的新手或同级的鸟。
同理：一个函数加一个null判断，得上升到百万次的调用级别的高度考虑，如果这判断被调用百万次，那性能不是大大的损失？
如果加2个判断，那就是2*百万次的调用，那就是相当大的性能损失，这怎么可以接受的呢？
所以，能不加就不加，加不加，等错误出来了再加。
其三：太懒了，这个本人是这么理解的说：
大伙都知道，中鸟写代码，基本都属于面向对象型的了，那就是天天和对象搞在一块的了，每个对象都要搞来搞去，再多的精也伤不起！
好吧，一个函数传一个参数，给你加一个判断，代码也不多，不算大括号就两行。
可是中鸟基本上写的函数的参数，偏偏三四五六七八九十个，这下让人纠结了：
加吧，一想，工作量太大了，而且这性能感觉不高；
不加吧，好像也没什么问题，这么一想啊，眼前阔然开朗，好，加不加，错误出来了再加。
还有的，不仅是参数的判断要折腾，函数内部产生的对象，也要搞一搞，太多对象要考虑。
光靠精力与考虑，加点人之常情，所以大多数情况是发生在：加不加，错误出来了再加！
老鸟：对这错误太熟悉，心也够细，写代码潜意识会主动加防，但百密一疏，该来的还是会来，躲过初一，躲不过十五。
老鸟吃的虫就更多了，而且老鸟们身经百战之后，觉得系统稳定，才是幸福。
个人猜测：老鸟写的代码，出现Null引用的原因可能是：
复制代码 代码如下:
其一：代码写多了，基本上都靠潜意识反应，就是说潜能发挥了，再白点就是习惯性思维。
所以基本上都不会怎么犯这错误，但是光靠潜意识，基本都能挡住，基本之外的，还得靠正常思维。
老鸟通常精力不太好，偶尔会走神，一走神，就漏了一个，再一走神，又漏了一个，再一走神，被神招唤了，太平间多了一位客人。
所以我写代码，尽量不走神，免的被招唤，但偶尔也会漏。
其二：是假老鸟，老鸟是装的，其实还是中鸟，硬要装，不过会装，说明智商高。
社会的法则表明，生存的越好的，装的程度越高，越会装，生活就越好，装到最高境界，那就是装孙子。
孙子是一名历史人物：会三十六计，装孙子的说明智商真的很高，没里绝对没有鄙视之意，因为三十六计有时候我也在学，只是智商一直上不去，所以境界一直上不去。
下面再补充一下，个人对中老鸟的看法，以下观点仅为作者扮演的个人的臆测观点，和作者本人无关：
中鸟何以追求性能？
复制代码 代码如下:
臆测：因为他们通常只接触到系统的一部分，缺少整个系统体系的了解，所以他们希望在他们负责的那一个区域里，写出性能至上的代码，这能说有错吗？
没错，而且理论上就应该这么干！但是，稳定不足，如果能写出又稳定又高性能的代码，有多好呢！
重点还是讲老鸟：老鸟何以不太关注性能，而求稳定？
其实，老鸟并不是不关注性能，而是他关注的是：
一：稳定，这个很重要：
复制代码 代码如下:
因为系统一上线：
首先：得对老板负责啊，你说是不是？
然后：如果这个产品是要给客户演示的，那得对客户负责啊，你说是不是？
再者：如果这个产品要上线运营，那得对访客负责啊，你说是不是？
所以，不管你系统怎么样，首先，保证稳定，至少给老板或客户或访客演示或操作的时候，你不能出错，至于慢点不慢点，那个好商量，好商量。
二：整体性能大于局部性能
复制代码 代码如下:
I：这个就很明显了，你一个算法写的很好，可是其它选手数据库写的差，一访问，很慢，这怎么说的过去。
II：所以要保证整体访问性能差不多先，然后再进行局部优化，这多符合中国人当前的优化思维啊。
III：再说了，每个人局部性能都最大化了，一访问，还是慢，找不到着优化的地方，这可是要出事的：老板得出血买硬件了。
IV：还有，整体上加了缓存+静态化html后，你会发现，局域的最大优化代码，基本都派不上用场了，因为直接就是访问+返回，
至于您那最大化性能的逻辑代码，那是千年走一回了。
当然了，个人对此观点是很负责的，绝对没有任何轻视局部性能最大化的意思，相反还得鼓励大伙局部性能最大化，努力写出最优代码：
复制代码 代码如下:
一来：这是每个码农往上走必经的阶段，跳过不是件好事。
二来：多让老板出下血，可以平衡下员工不满的心情：你让我加班，我就让你出血，多好呢。
重大说明：
本篇文章绝大多数观点为作者扮演的个人的臆测观点，和本人无关，本人认为，以上观点有些片面，可能与客观事实不符。
请各位看客看在周末的份上，少一份偏激，多一份激动，开X吧！
本视频到此为止，欢迎收看，下次再会，谢谢！
PS：最近顺路折腾了下 CYQ.Data V4.5离线帮助文档，很快发布，敬请关注。
相关文章
.NET/C#如何判断某个类是否是泛型类型或泛型接口的子类型详解
这篇文章主要给大家介绍了关于.NET/C#如何判断某个类是否是泛型类型或泛型接口的子类型的相关资料，文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值，需要的朋友们下面来一起看看吧2018-09-09
这篇文章主要为大家详细介绍了NetCore1.1+Linux部署的初体验，具有一定的参考价值，感兴趣的小伙伴们可以参考一下2017-06-06
asp.net 获取系统中参数的实现代码，需要的朋友可以参考下。2011-12-12
我们要进行微信公众平台的开发，第一步当然是要有公众号了。什么？不知道什么是微信公众号，看来你还要先回炉炼炼了，呵呵。通俗的说，我们微信平台就好像是一个大社会，里面有个体人，也有各种组织机构。2016-05-05
本文通过实例代码给大家介绍了Devexpress中Gridcontrol查找分组的方法，非常不错，具有一定的参考价诶接价值，需要的朋友一起看看吧2018-08-08
这篇文章介绍了repeater做删除前弹窗询问实例，有需要的朋友可以参考一下2013-10-10
这篇文章主要介绍了如何将Winform移植到.NET Core 3.0，文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值，需要的朋友们下面随着小编来一起学习学习吧2020-03-03
ASP.NET文件包含的方法基本与ASP文件包含差不多!2010-03-03
清空cookie2008-07-07
ASP.NET Core AutoWrapper 自定义响应输出实现
这篇文章主要介绍了ASP.NET Core AutoWrapper 自定义响应输出实现，文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值，需要的朋友们下面随着小编来一起学习学习吧2020-08-08
最新评论