在上篇：周末浅说--未将对象引用设置到对象的实例(System.NullReferenceException) 中，介绍了一个比较经典的异常。
文中并浅出一些个人观点，又潜伏一些观点。
本节将从上篇的文章中，引申潜伏在上文的另一个主题：异常霸气外露！找死！
先不说网友以前是怎么认识try catch和异常的处理，这里先给出两个示例代码：
1：循环20万次的判断，看时间：
static void Main(string[] args)
{
System.Diagnostics.Stopwatch watch = new System.Diagnostics.Stopwatch();
watch.Start();
for (int i = 0; i < 200000; i++)
{
try
{
if (a != null)
{
a.ToString();
}
}
catch
{ }
}
watch.Stop();
System.Console.WriteLine(watch.ElapsedMilliseconds);
Console.Read();
}
本机的结论是：0毫秒
这里只是想最直白的说明一下：加一个判断，并不影响性能。
2：循环1次，抛异常并捕获
static void Main(string[] args)
{
System.Diagnostics.Stopwatch watch = new System.Diagnostics.Stopwatch();
watch.Start();
for (int i = 0; i < 1; i++)
{
try
{
//if (a != null)
//{
a.ToString();
//}
}
catch
{
}
}
watch.Stop();
System.Console.WriteLine(watch.ElapsedMilliseconds);
Console.Read();
本机的结论是：2毫秒
这里只是想最直白的说明一下：1个异常的抛出的时间，能挡住60万次的判断。
这个结论同时表明：加判断，并不是不重视性能，反而正是性能最直白的体现。
在个人的印象中，前人就有文章指出异常对性能的影响，当然这个可能年代太久了，大伙没啥印象了。
今天本人只是换个角度，换个方式，去传达这么一种理念：异常应该避免，而不是捕获，捕获，那是不得已而为之。
这里再顺路推出微软一个让人纠心的未处理的异常：Dictionary<T,T>的Add方法：
{
try
{
dic.Add(key, info);
}
catch
{
//反编绎微软内部调用：private void Insert(TKey key, TValue value, bool add) 可能会抛异常：Index was outside the bounds of the array
}
}
正常的写法，是不用加try catch，可是微软也不是百分百完美的，就像我下面注释的异常，有一定的小概率会抛异常出来，不得已捕获之。
好，懂事的看完上面的内容，基本都明白事理了，下面再扯几句给不怎么懂事的清闲清闲：
霸气外露！找死！-- 这是发哥在让子弹飞的话，今天借来一用！
这里从两个角度上发挥一下：
1：假设我们很注重性能
以前常整天忙碌在用S好还是用B好，精心设计来设计去，减少来减少去，折腾来折腾去还不一定有60万这么大数字，现在一看，蒙了！
原来家里还有这么一只超级大老鼠，整天吃性能，以前竟然没发现！！！不过今天。。。
异常霸气外露！找死！
霸气外露，遇到我们这群性能执法者，纯找死！得把你给灭了，灭一个就是省60万，灭两个就是省120万，灭多几个，房子车子全有着落了！
2：假设我们不是很关注性能
反正秒级以下的都问题不大：抛500个异常也无所谓了，就一两秒的时间。
G要的是稳定，稳定！！！明了？
不过话说回来，虽然不在乎点时间，可是这。。。
异常霸气外露！找死！
我们领导最恨的就是异常，还霸气外露，露多几下G这饭碗还能握的住么？不行，不管什么异常，得坚决的消灭，消灭不掉的，得藏起来，坚决不能让它外露！
这不，那个车头不就是霸气外露，才被埋的么！！！
顺路PS： CYQ.Data V4.5离线帮助文档，很快发布，敬请关注。
