八月底、九月初这段时间出现使用Chrome访问msdn的页面返回The specified CGI application encountered an error and the server terminated the process.的问题。但是IE没有问题。刚开始没有找到原因,忍痛,不能用心爱的Chrome浏览msdn。只能另外开启一个IE专门查看。别提多别扭了。
知道今天看到一个网友写道他的FF也遇到问题,解决办法是清空了Cookie于是试了一下,果然问题得到了解决。但是如何导致问题发生的根源还不清楚,如果哪位网友清楚的还望教我。

WMIC http://blogold.chinaunix.net/u3/94687/showart_2045762.html
守护进程 http://www.cnblogs.com/WGZ_Home/archive/2011/02/20/1958437.html
原文地址
http://www.cnblogs.com/TeckyLi/archive/2011/02/20/1959164.html
留下来,有时间自己琢磨琢磨异常处理。
这几天看C#基础书籍中关于异常处理部分的内容,总结一下我的收获,呵呵!
总共有以下几个收获:
- 如何能有一个机制在APP最顶层捕获到所有抛出的异常(包括被捕获的和未被捕获的),而又不影响App内部处理每个异常的方式?
- 捕获异常私了还是将异常简单处理后继续抛出?
- 如何快速高效的定义自己的异常类型?
下面详细谈一谈:
捕获应用程序域中抛出的所有异常
在开发过程中,有时候我们可能需要有一个统一的接口来处理所有当前托管代码中任何位置抛出的异常。实际上,由于很多的异常在代码的不同位置被我们自己写的代码已经捕获了,而有些代码又没有被捕获,还有些异常是被捕获之后又重新被抛出了,等等。其实,AppDomain这个对象上有一个很重要的事件,那就是FirstChanceException,这个事件可以在一个异常触发后,而且是在未被其他代码捕获前首先触发该事件,并把异常对象包含在FirstChanceExceptionEventArgs中,换句话说,该事件能够在第一时间向我们报告任何一个被抛出的异常,包括Re-Throw,下面是它的声明:
// // Summary: // Occurs when an exception first occurs in managed code, before the runtime // has made its first pass searching for suitable exception handlers. public event EventHandler<FirstChanceExceptionEventArgs> FirstChanceException;从注释上已经可以看到,该事件可以让我们尝到最新鲜、最及时的异常。
下面是我写的一个Demo例子,来观察一下它的行为。首先是在main函数中对currentDomain注册FirstChanceException事件的处理方法。
static void Main(string[] args) { AppDomain.CurrentDomain.FirstChanceException += new EventHandler<System.Runtime.ExceptionServices.FirstChanceExceptionEventArgs>(CurrentDomain_FirstChanceException); SimpleExceptionTest.Test(); Console.ReadLine(); } static void CurrentDomain_FirstChanceException(object sender, System.Runtime.ExceptionServices.FirstChanceExceptionEventArgs e) { Console.WriteLine("CurrentDomain_FirstChanceException:"); Console.WriteLine(e.Exception); Console.WriteLine(); Console.WriteLine(); }然后我编写了一个可以抛出异常的并能自己捕获的SimpleExceptionTest类:
class SimpleExceptionTest { static void TestInner() { try { Console.WriteLine("Exec in Try block!"); object o = null; Console.WriteLine(o.GetType()); } catch (NullReferenceException e) { Console.WriteLine("Exec in catch block! "); Console.WriteLine(e.Message); Console.WriteLine("Exec end catch block! "); throw; } finally { Console.WriteLine("================Exec in finally block!"); int i = 0; //finnally 块中产生异常 int j = 5 / i; Console.WriteLine("================Exec end in finally block!"); } } public static void Test() { try { TestInner(); } catch (Exception e) { Console.WriteLine(e.Message); } } }程序执行的结果如下:
Exec in Try block!
CurrentDomain_FirstChanceException:Object reference not set to an instance of an
object.Exec in catch block!
Object reference not set to an instance of an object.
Exec end catch block!CurrentDomain_FirstChanceException:Object reference not set to an instance of an
object.================Exec in finally block!
CurrentDomain_FirstChanceException:Attempted to divide by zero.
Attempted to divide by zero.
从上面的执行结果可以看出如下几个问题:
- CurrentDomain_FirstChanceException总是在第一时间捕获到了异常,包括在Catch块中ReThrow的异常。
- Finnally块中抛出异常时,中断了Finally块的执行。我们知道,在Finally块中,通常是写一些清理性的代码,比如释放Try中开启的资源,关闭Try中启动的等待窗等等。所以如果你的finally中又会抛出异常的话,清理工作就会中断了。
那么如何才能保证Finnally块中的清理工作一定能够正确完成哪,我们难道要在Finally块中嵌套一个TryCatchFinnally语句吗,这将会形成死循环的,最后一个Finnally总是没有保证的。唯一可行的办法就是在finnally中不要放置多余的代码,并且认真的写出高质量的清理代码,以祈求它不要再抛出异常。
捕获异常私了还是将异常简单处理后继续抛出
这个问题也是很多初学者的疑惑。我认为有以下几个原则:
1、只私了自己可以明确知道如何处理的异常,比如 从业务和项目组的约定来看,当除以0发生时,我们都将该表达式的值返回0。 那么这就是一个处理异常的法规,依据它就可以将这个异常私了,使异常止步于此,不再向调用堆栈上层抛出。
2、你是一个独立的模块,而且有需要要求你必须做到决定的健壮,那么你可以捕获所有的异常,能处理的依照法规私了,不能处理的就记录或者将异常以友好的方式报告给用户或者服务器,但是程序并不会因此而崩溃。
3、不知道如何处理的异常,自己捕获到后,进行简单处理(比如将异常包装一下,加上更加明确的异常出现位置啊,异常触发时的业务参数信息等)再抛出,交给调用堆栈的上层去捕获后处理。
如何快速高效的定义自己的异常类型
自定义一个异常,其实挺简单的,只要定义一个类并继承自System.Exception或其子类即可。但是那会造成异常类型繁多冗杂,我们自己的团队成员都会记不清楚该有多少异常需要捕获了。而且定义一个符合业务需要的异常又谈何容易。
下面推荐一个CLR via C#一书中定义的异常泛型类Exception<TExceptionArgs> ,只要定义一个新的TExceptionArgs,就能可以让我们获得一个实用的自定义异常类型。
[Serializable] public sealed class Exception<TExceptionArgs> : Exception, ISerializable where TExceptionArgs : ExceptionArgs { private const String c_args = "Args"; // For (de)serialization private readonly TExceptionArgs m_args; public TExceptionArgs Args { get { return m_args; } } public Exception(String message = null, Exception innerException = null) : this(null, message, innerException) { } public Exception(TExceptionArgs args, String message = null, Exception innerException = null) : base(message, innerException) { m_args = args; } // The constructor is for deserialization; since the class is sealed, the constructor is // private. If this class were not sealed, this constructor should be protected [SecurityPermission(SecurityAction.LinkDemand, Flags = SecurityPermissionFlag.SerializationFormatter)] private Exception(SerializationInfo info, StreamingContext context) : base(info, context) { m_args = (TExceptionArgs)info.GetValue(c_args, typeof(TExceptionArgs)); } // The method for serialization; it’s public because of the ISerializable interface [SecurityPermission(SecurityAction.LinkDemand, Flags = SecurityPermissionFlag.SerializationFormatter)] public override void GetObjectData(SerializationInfo info, StreamingContext context) { info.AddValue(c_args, m_args); base.GetObjectData(info, context); } public override String Message { get { String baseMsg = base.Message; return (m_args == null) ? baseMsg : baseMsg + " (" + m_args.Message + ")"; } } public override Boolean Equals(Object obj) { Exception<TExceptionArgs> other = obj as Exception<TExceptionArgs>; if (obj == null) return false; return Object.Equals(m_args, other.m_args) && base.Equals(obj); } public override int GetHashCode() { return base.GetHashCode(); } } [Serializable] public abstract class ExceptionArgs { public virtual String Message { get { return String.Empty; } } } }下面我使用这个泛型异常类来构造自己的异常类型:
首先定义一个计算两个城市距离的异常参数类,继承自ExceptionArgs。
[Serializable] public sealed class CalcDistanceErrorArgs : ExceptionArgs { string m_cityId1 = string.Empty; string m_cityId2 = string.Empty; public CalcDistanceErrorArgs(string cityId1, string cityId2) { this.m_cityId1 = cityId1; this.m_cityId2 = cityId2; } public override string Message { get { return string.Format("city1'id = '{0}', city2 'id = '{1}' ", m_cityId1, m_cityId2); } } }然后编写一个函数,抛出一个这样的异常:
public static void ThrowMyOwnExceptionType() { throw new Exception<CalcDistanceErrorArgs>(new CalcDistanceErrorArgs("NanJing", "Beijing"), "获取不到这两个城市之间的距离"); }使用下面的代码捕获异常:
try { ThrowMyOwnExceptionType(); } catch (Exception<CalcDistanceErrorArgs> e) { Console.WriteLine(e); }运行时,我们查看异常如下图所示:
运行输出的异常信息如下:
ConsoleApplication1.Exception`1[ConsoleApplication1.CalcDistanceErrorArgs]: 获取不到这两个城市之间的距离 (city1'id = 'NanJing', city2 'id = 'Beijing' )
at ConsoleApplication1.SimpleExceptionTest.ThrowMyOwnExceptionType() in D:\Study Prj\ConsoleApplication1\ConsoleApplication1\SimpleExceptionTest.cs:line 57
at ConsoleApplication1.SimpleExceptionTest.Test() in D:\Study Prj\ConsoleApplication1\ConsoleApplication1\SimpleExceptionTest.cs:line 47好了,希望这个泛型异常类对您自定义异常有所帮助吧。
原文地址
http://www.cnblogs.com/xuld/archive/2011/02/20/1958933.html#pagedcomment
本文面向玩代码玩的蛋疼的读者。
库和框架都是一种有别于软件、面向程序开发者的产品形式。正因为如此,也有很多人误以为库就是框架,或者认为指定语言的库就是框架。
库的英语为 Library ( 简写 Lib ),框架的英语为 Framework。
库是将代码集合成的一个产品,供程序员调用。面向对象的代码组织形式而成的库也叫类库。面向过程的代码组织形式而成的库也叫函数库。
在函数库中的可直接使用的函数叫库函数。开发者在使用库的时候,只需要使用库的一部分类或函数,然后继续实现自己的功能。
框架则是为解决一个(一类)问题而开发的产品,框架用户一般只需要使用框架提供的类或函数,即可实现全部功能。可以说,框架是库的升级版。
开发者在使用框架的时候,必须使用这个框架的全部代码。
框架和库的比较可以想像为:
假如我们要买一台电脑。框架为我们提供了已经装好的电脑,我们只要买回来就能用,但你必须把整个电脑买回来。这样用户自然轻松许多,但会导致
很多人用一样的电脑,或你想自定义某个部件将需要修改这个框架。而库就如自己组装的电脑。库为我们提供了很多部件,我们需要自己组装,如果某个部件
库未提供,我们也可以自己做。库的使用非常灵活,但没有框架方便。
常说的 C函数库、 .net框架 就体现了框架和库的区别:
C中库函数需要自己 #include
.net 中,所有程序都引用了 mscore.dll (System 名字空间)
原文地址:http://www.cnblogs.com/susy/archive/2011/01/16/1936971.html
近日开始读Bob大叔的《Agile Principles, Patterns, and Practices in C#》,到今天看了前10章,最大的感觉就是:代码、设计、架构都是根据需求变化而不断增长的。静态地、孤立地看代码、设计是没什么意义的。同样的代码、同样的设计在开始阶段可能是非常好的、足够用的、再过之就over-design的;但在两周之后、新需求增加之后再不调整就充满各种bad smells。
之前上过一个软件开发的培训,老师教我们软件开发的流程是拿到需求之后,先进行详细的OOA(面向对象分析)、OOD(面向对象设计),画出系统的Class diagram(类图)以及 sequence diagram;然后再找N多专家、架构师开会复审,根据反馈再进行修改、确认定稿;最后再依据最终稿实现。按照这个流程,理论上系统最终的架构、代码都应该相对漂亮、干净、易维护才对啊,可为什么到最后我们的代码还是让人觉得差、设计还是让人觉得乱呢?
其实,不能否认,经过仔细分析设计、专家评审通过的那些架构肯定是优雅漂亮能解决问题的。可是,它是针对当时的需求、当时设计人员对需求的理解而言的,它是静态的在那一点时的足够好。但是,它也存在不足。首先在没有实现、没有编码之前,设计人员不可能预见到所有的问题,所以前期的设计总是会存在一些没有考虑到的漏洞;其次专家们可能对该系统的了解可能还没有设计人员深,虽然他们功力深厚、经验丰富,但在这种情况下也只能是从大的方面帮设计人员把关,确保一些大的方面的架构、设计不出现偏差,至于细节上也不能面面俱到了。在这种情况下,设计人员开发时遇到那些没有预见的问题如果没有很好的重新设计(在时间的压迫下),而是凑合根据现有的设计实现它,那么,问题代码、问题设计就出现了。
敏捷开发和敏捷设计就可以很好的处理这个问题了。敏捷天生就是处理动态变化的。敏捷设计的观点是,需求来了之后,首先选出接下来两周你要做什么,然后对这些选出的工作进行简单的分析设计并开始编码,用简单且足够好的设计、编码来实现这些功能,并且用Unit Test来测试这些实现、来迫使你自己从一个用户的观点来看待这些实现是不是合理、时不时覆盖到各种情况。当Unit Test发现你之前没有预见到的情况时,更改你的代码和设计来实现它,并且重构你的代码和设计、保证他们还是足够好。用单元测试保证你高质量的进行增量是开发,用重构保证你代码设计总是足够好,用敏锐的嗅觉保证你及时重构。敏锐的嗅觉来源于对代码、设计的bad smells的熟悉和了解。
好的代码、好的设计是不断成长的,是需要不断维持的。一旦被程序员有意或无意的忽略,再想找回它们来就难了。
原文地址 http://coolshell.cn/articles/3463.html
对于SQL的Join,在学习起来可能是比较乱的。我们知道,SQL的Join语法有很多inner的,有outer的,有left的,有时候,对于Select出来的结果集是什么样子有点不是很清楚。Coding Horror上有一篇文章(实在不清楚为什么Coding Horror也被墙)通过 文氏图 Venn diagrams解释了SQL的Join。我觉得清楚易懂,转过来。
假设我们有两张表。
- Table A是左边的表。
- Table B是右边的表。
其各有四条记录,其中有两条记录是相同的,如下所示:
id name id name -- ---- -- ---- 1 Pirate 1 Rutabaga 2 Monkey 2 Pirate 3 Ninja 3 Darth Vader 4 Spaghetti 4 Ninja
下面让我们来看看不同的Join会产生什么样的结果。
SELECT * FROM TableA INNER JOIN TableB ON TableA.name = TableB.name id name id name -- ---- -- ---- 1 Pirate 2 Pirate 3 Ninja 4 Ninja Inner join |
![]() |
SELECT * FROM TableA FULL OUTER JOIN TableB ON TableA.name = TableB.name id name id name -- ---- -- ---- 1 Pirate 2 Pirate 2 Monkey null null 3 Ninja 4 Ninja 4 Spaghetti null null null null 1 Rutabaga null null 3 Darth Vader Full outer join 产生A和B的并集。但是需要注意的是,对于没有匹配的记录,则会以null做为值。 |
![]() |
SELECT * FROM TableA LEFT OUTER JOIN TableB ON TableA.name = TableB.name id name id name -- ---- -- ---- 1 Pirate 2 Pirate 2 Monkey null null 3 Ninja 4 Ninja 4 Spaghetti null null Left outer join 产生表A的完全集,而B表中匹配的则有值,没有匹配的则以null值取代。 |
![]() |
SELECT * FROM TableA LEFT OUTER JOIN TableB ON TableA.name = TableB.name WHERE TableB.id IS null id name id name -- ---- -- ---- 2 Monkey null null 4 Spaghetti null null 产生在A表中有而在B表中没有的集合。 |
![]() |
SELECT * FROM TableA FULL OUTER JOIN TableB ON TableA.name = TableB.name WHERE TableA.id IS null OR TableB.id IS null id name id name -- ---- -- ---- 2 Monkey null null 4 Spaghetti null null null null 1 Rutabaga null null 3 Darth Vader 产生A表和B表都没有出现的数据集。 |
![]() |
还需要注册的是我们还有一个是“交差集” cross join, 这种Join没有办法用文式图表示,因为其就是把表A和表B的数据进行一个N*M的组合,即笛卡尔积。表达式如下:
SELECT * FROM TableA CROSS JOIN TableB
这个笛卡尔乘积会产生 4 x 4 = 16 条记录,一般来说,我们很少用到这个语法。但是我们得小心,如果不是使用嵌套的select语句,一般系统都会产生笛卡尔乘积然再做过滤。这是对于性能来说是非常危险的,尤其是表很大的时候。
类与类关系的UML图与代码表现[转]
http://www.cnblogs.com/zhangzt/archive/2010/10/25/1860568.html?login=1#commentform
《哥乃一届光棍》
http://www.cnblogs.com/zhushaohua95/archive/2010/11/11/1875265.html







