首先让我们认识一下IOutput这个接口,这个接口主要描述了报告日志的输出形式,里面只定义了一个方法(如果以后使用时发现不能满足需求,可以多加入一些描述信息和方法处理):
不过,在目前的这个组件中我对这个接口只有一个实现,就是报告异常信息到Windows日志管理器,以后我们可以增加更多的实现IOutput接口的类来完成日志的输出,异常报告使用了.Net类库中的System.Diagnostics命名空间,将一些参数通过调用EventLog.CreateEventSource方法写入日志,这一部分的代码如下,很简单的:
我在文章中会把类似这样的实现称为日志输出处理器(简称处理器,有点像CPU啊),我们还可以实现类似写日志到数据库,写日志到文件系统,甚至发送日志到管理员的邮箱中等,这一部分如果有时间的话都可以进行扩展.当然这也就给组件带来一定的扩展功能,抽象出接口就有这样的好处.如果继续完善的话,可以把这一部分做成一个Config来让开发者自己配置完成,这一部分我打算在本系列的第二部分进行介绍.
让我们接下来看看组件的主要部分异常发掘机吧,它是主要将异常整理并通过上面的接口发送出去的类,这一部分在封装时同样考虑了以后的扩展问题,定义一个output,可以将任何实现了IOutput接口的对象赋予它,在实际上执行时output.OutputLog是稳定的,此外关于output变量的赋值我会在本系列的第二部分通过定义Config由用户自己指定,在这里我就使用了组件中的唯一的处理器EventLogsOutput来完成.异常发掘机使用了.Net的委托,主要是为了使用上的方便而采用,用户甚至可以定义自己的处理程序来完成日志的提交.默认情况下使用EventLogsOutput提交,当Exception属性改变时执行提交,类中对一些描述异常的成员使用了Static定义,主要想保存最后一个异常信息,同样是为以后扩展与修改方便,此外注意它对外提供了两个构造器来完成,没有参数的是采用默认的方式,带有参数的是为了扩展提供的:
这一部分使用了事件处理模型对异常进行提交, ExObjectInfo是对异常信息进行的一个简单的封装,主要是为参数传递方便使用:
在解决方案中还有一个TestDebuger项目,这是我的一个Demo测试项目,启动这个项目执行以后调用一个方法将抛出的异常发送出去:
其中:
这就是异常报告组件的使用,将提交的参数付给一个Object的数组,如果参数是引用的类型,就会调用对象的ToString方法转换成字符串输出.执行以后我们可以打开Windows日志查看器进行日志的查看:
![](https://www.cnblogs.com/images/cnblogs_com/thriving-country/debuger20080701/Event.JPG)
选择程序抛出的错误信息可以看到:
![](https://www.cnblogs.com/images/cnblogs_com/thriving-country/debuger20080701/EventDetail.JPG)
==========begin==========
Tuesday, 01 July 2008 11:34
Module:CatchExceptionmMethod
Parameters:[para2=24;para3=Person'name is thricing.country, person'age is 24;para1=thricing.country;]
Message:这是一个异常
Trace: 在 TestDebuger.Program.CatchExceptionmMethod(String para1, Int32 para2, Person para3) 位置 D:\work\MyDebuger\TestDebuger\Program.cs:行号 27
===========end===========
上面的信息已经可以让程序员找到问题的所在了吧.
这个组件在设计时考虑到以下几个可以扩展的地方:
1.异常发掘机中的几个异常描述参数使用Static关键字进行定义,主要考虑到这里如果经过简单修改可以存储系统中最后抛出的异常以便进行跟中.
2.异常发掘机提供了两个构造器,没有参数的实现的是默认的处理方式,使用第二个带有一个委托的构造器可以对异常的报告采用一种用户自定义的方式完成.
3.我们可以对实现IOutput接口的处理器配置指派,用户还可以自定义一个全新的处理器进行使用.
在第二部分我将主要对这个组件的配置部分进行开发,用以完成使用者可以通过配置轻松的完成处理器的选择.
源代码下载:
MyDebugerAndDemo_SRC20080701.rar