在上篇:周末浅说--未将对象引用设置到对象的实例(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离线帮助文档,很快发布,敬请关注。
版权声明:本文原创发表于 博客园,作者为 路过秋天 本文欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则视为侵权。 |
个人微信公众号 |
Donation(扫码支持作者):支付宝: |
Donation(扫码支持作者):微信: |