 跟踪
Win32 调试 API 到哪都是一个便利的工具。OutputDebugString 函数可被添加到程序中提供动态跟踪，这样你就可以使用 DbgView.exe
（(http://www.sysinternals.com）或者 DBMON（随 Platform SDK 一起提供）之类的工具看到程序的调试信息。你甚至可以从远程机器连接到它。.NET
Framework 在跟踪实现上仍然利用了这些 API，这是我下面要讨论的内容。
逆风编程精品
跟踪是一个很好的主意。你想看看在什么条件下用到了哪些方法：ASP.NET在 System.Web.TraceContext 类中提供了 Trace 方法机制，而基础类库（BCL）在 System.Diagnostics 名字空间中提供了 Trace 和 Debug 类。为了在程序中使用 System.Diagnostics
进行跟踪，必须在你的代码中加入跟踪语句并确认跟踪在编译时是被允许的。跟踪语句有好几种类似的形式。最常用的形式就像下面的：
System.Diagnostic.Trace.WriteLine("something useful")
System.Diagnostics.Trace 和 System.Diagnostics.Debug 都是封装好的类。
它们之间的主要差别在于条件编译字符串常常在生成过程中包含这些类的调用。Debug 类方法只有在 DEBUG 编译常量被设置时才会被编译到生成过程中去。而只
有设置了 TRACE 常量，Trace 方法才会被编译到任何生成过程中（具体细节参见 SDK 文档）。在程序的 .config 文件中还可以设置跟踪级别
，这样你就有几种手段控制实际产生的信息的详细程度。
使用 System.Diagnostics 名字空间你还可以编写自己的跟踪监听器类并把它们加入到 Trace 或 Debug Listeners 集合。当 CLR 执行
某个 Trace 或 Debug 语句时，集合中的所有监听器会被依次调用。调试跟踪提供的 DefaultTraceListener 在该集合中总是缺省的。而框架也会使用 EventLogTraceListener
将这些消息转储到当前日志，并使用 TextWriteTraceListener 将它们写到流中。
结构化异常
结构化异常处理（SEH）是.NET托管环境最好的特性之一。从 Visual Basic 6.0 的观点看，这是一个在 On Error
语句上所做的奇特的改进。你可以明确的捕捉一个异常因为你知道如何处理它们，或者你什么也不作而让别人在这个异常链的更高层上捕捉到它。
Figure 2 日志异常
但如果你仅仅是为此使用 SEH，那么你就会遗漏许多东西。你可以实现你自己的异常基类，而所有其它定制异常都从它派生。在其内部你可以捕捉到相关的环境数据（比如当前用户名和线程ID）
，这样你就有了一个完整的日志记录所发生的一切，这样就使你能做出更佳的异常情况评估并按需要产生管理报告。Figure 2 举例说明了某个异常被传播到调用链
的过程，调用链再将它送给能记录它们的通用处理例程。你可以用任何方法记录这些日志，但数据库通常是最有效的（不幸的是，你还需要做许多工作）。如果异常日志
机制是时间敏感的，它也可以异步完成，以便在将异常信息存储到日志时应用程序能够继续执行。
WMI
WMI 是目前 Windows 中最强大，最复杂的检测机制。在 .NET Framework 之前，人们对它的评价就是难以使用。这主要是因为 Visual Basic 6.0 之类的
RAD（快速应用程序开发）工具很难使用 WMI API 的缘故。WMI 是很大的——只要看一下SDK文档就明白了。幸运的是为了使用其最佳特性，你可以不必完全理解它。例如，加入一个
对 System.Management.dll 的引用，你就可以写出下面的代码：
Imports System.Management.Instrumentation _
<System.ComponentModel.RunInstaller(True), _
InstrumentationClass(InstrumentationType.Event)>_
Public Class MyEvent
'' event "property"
Public EventProperty as String
end Class
本文章更多内容：<<上一页 - 1 - 2 - 3 - 4 - 5 - 6 - 7 - 8 - 9 - 10 - 下一页>> | 
您的位置：逆风者
→ VC++
→ 正文
本文章所属分类：首页
→ VC++