在上篇：週末淺說--未將物件引用設定到物件的例項(system.nullreferenceexception)中，介紹了乙個比較經典的異常。
文中並淺出一些個人觀點，又潛伏一些觀點。
本節將從上篇的文章中，引申潛伏在上文的另乙個主題：異常霸氣外露！找死！
先不說網友以前是怎麼認識try catch和異常的處理，這裡先給出兩個示例**：
static
object
a;static
void
main(
string
args)
}catch
}watch.stop();
system.console.writeline(watch.elapsedmilliseconds);
console.read();}
本機的結論是：0毫秒
這裡只是想最直白的說明一下：加乙個判斷，並不影響效能。
2：迴圈1次，拋異常並捕獲
static
object
a;static
void
main(
string
args)
}catch
}watch.stop();
system.console.writeline(watch.elapsedmilliseconds);
console.read();
本機的結論是：2毫秒
這裡只是想最直白的說明一下：1個異常的丟擲的時間，能擋住60萬次的判斷。
這個結論同時表明：加判斷，並不是不重視效能，反而正是效能最直白的體現。
在個人的印象中，前人就有文章指出異常對效能的影響，當然這個可能年代太久了，大夥沒啥印象了。
今天本人只是換個角度，換個方式，去傳達這麼一種理念：異常應該避免，而不是捕獲，捕獲，那是不得已而為之。
這裡再順路推出微軟乙個讓人糾心的未處理的異常：dictionary的add方法：
if(!
dic.containskey(key))
catch}
正常的寫法，是不用加try catch，可是微軟也不是百分百完美的，就像我下面注釋的異常，有一定的小概率會拋異常出來，不得已捕獲之。
好，懂事的看完上面的內容，基本都明白事理了，下面再扯幾句給不怎麼懂事的清閒清閒：
霸氣外露！找死！-- 這是發哥在讓子彈飛的話，今天借來一用！
這裡從兩個角度上發揮一下：
1：假設我們很注重效能
假充我們很注重效能：現在我們明白了，乙個異常不經易的丟擲，就害我們損失了60萬次的判斷，唉喲媽喂，這得嚇死多少千年蟲！
以前常整天忙碌在用s好還是用b好，精心設計來設計去，減少來減少去，折騰來折騰去還不一定有60萬這麼大數字，現在一看，蒙了！
原來家裡還有這麼乙隻超級大老鼠，整天吃效能，以前竟然沒發現！！！不過今天。。。
異常霸氣外露！找死！
霸氣外露，遇到我們這群效能執法者，純找死！得把你給滅了，滅乙個就是省60萬，滅兩個就是省120萬，滅多幾個，房子車子全有著落了！
2：假設我們不是很關注效能
假設我們不是很關注效能：乙個異常2毫秒，多大點屁事，60萬次判斷？你家的啥cpu？沒個上百次你都不好意思上來說了。
反正秒級以下的都問題不大：拋500個異常也無所謂了，就一兩秒的時間。
g要的是穩定，穩定！！！明了？
不過話說回來，雖然不在乎點時間，可是這。。。
異常霸氣外露！找死！
我們領導最恨的就是異常，還霸氣外露，露多幾下g這飯碗還能握的住麼？不行，不管什麼異常，得堅決的消滅，消滅不掉的，得藏起來，堅決不能讓它外露！
這不，那個車頭不就是霸氣外露，才被埋的麼！！！
順路ps：cyq.data
效能殺手之異常霸氣外露！找死！
在上篇 週末淺說 未將物件引用設定到物件的例項 system.nullreferenceexception 中，介紹了乙個比較經典的異常。文中並淺出一些個人觀點，又潛伏一些觀點。本節將從上篇的文章中，引申潛伏在上文的另乙個主題 異常霸氣外露！找死！先不說以前是怎麼認識try catch和異常的處理，...
警惕無形效能殺手 快取行失效
在我們的程式中，有一類埋藏極深的問題，其可能導致我們的程式效能數量級的下降，它就是快取行失效。它是因為 cpu 的結構設計而導致的，與語言無關。本篇 chat 會以例子的形式介紹問題的表現，介紹相關的背景知識，分析問題的根本，並且給出解決方案。在本場 chat 中，你將了解到以下知識 快取行失效時導...
效能和異常日誌
1 效能日誌主要記錄某個模組執行的時間，用stopwatch來記錄模組執行的時間。如果執行的時間超過設定的時間 如200毫秒 則記錄日誌，如果客戶端響應時間較長，可以通過檢視效能日誌，定位某個模組的出現了問題。2 異常日誌，在try catch 裡把異常資訊 記錄到異常日誌檔案，找到異常相關資訊。3...