未將對象引用設置到對象的實例 (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離線幫助文檔,很快發布,敬請關注。

相關文章

最新評論

精品国内自产拍在线观看