4.捕获错误,测试与调试

捕获错误，测试与调试

本章内容

●连接到目标

●编译时错误

●异常处理：与完整版.NET Framework一致

●运行时异常

●全局异常处理

●几种重要的异常

●日志文件

●手段

●单元测试

本章将讨论如何连接到仿真器或设备，以便能在开发过程中对代码进行调试。您会学习到在运行时的各种错误类型，如何编写程序来捕获并处理的异常。您还将学习Microsoft .NET Compact Framework运行库生成的各种日志文件，了解如何使用它们对特定的错误进行诊断，了解如何将追踪消息输出到IDE，或将其写入部署后的应用程序活动日志中，这些为人们提供了诊断的工具。

4.1 连接到目标

在讨论调试技术、最优异常处理技术和一般场景下的除错技巧之前，必须先了解如何连接到Microsoft Visual Studio的“目标”上。这个目标可以是一个真实设备，也可以是一个仿真器。在本书的后续部分，我们所提到的目标、设备、仿真器都是可互相替代的。

远程工具

Visual Studio 2005是一个单独的开发工具，既可供托管开发者使用，也可供本地开发者使用。而在此之前，本地开发者不得使用嵌入式Microsoft Visual C++ IDE来进行开发。整合的好处之一，是曾经在嵌入式Visual C++中存在而在Visual Studio .NET 2003中空缺的远程工具，现在都被收到Visual Studio 2005中，并同时开放给这两类开发者(如图4.1所示)。

图4.1可以在开始菜单中Visual Studio下的Remote Tools中找到

“远程放大”(Remote Zoom In)可以非常方便地对设备进行截图(bitmap)。“远程注册表编辑器”(Remote Regsitry Editor)允许开发者进入并更改远程目标中的注册表，它是一个很常用的工具。“远程文件查看器(Remote File Viewer)”可以替代Microsoft ActiveSync技术来对远程目标上的文件系统进行读/写(包括导入和导出)。“远程查看器”(Remote Spy)类似于它在桌面上的等价物，可以用它来浏览活动窗口和发送给每个窗口句柄(window handle)的消

“远程进程查看器”(Remote 息，它并不是平时所用的工具，但若是需要，使用起来会非常方便。

Process Viewer)用于查看目标上当前运行的进程列表、这些进程所拥有的线程及所加载的模块，也可以用来销毁进程。最后的“远程堆查看器(Remote Heap Walker)”的作用被托管开发削弱了，因为托管程序开发者一般并不关心用于托管进程堆的标识符(identifier)和标志(flag)。

远程工具降低了一地(PC)开发异地(设备)运行的难度。在.NET Compact Framework version 2.0 Service Pack 1中有另外一个工具“远程性能监视器”(Remote Performance Monitor，RPM)。RPM将在第5章讲解。

4.1.1 设备

设备的连接功能由ActiveSync (AS)4.x 版(或Windows Vista操作系统上的Windows Mobile设备中心[WMDC]，正如第1章所述)来提供。如果您拥有Windows Mobile设备，可能已经将它通过USB(universal serial bus)连线连接到计算机上。这个软件和连线一般是每个Windows Mobile设备的附件。ActiveSync允许通过USB进行连接，也允许通过蓝牙(Bluetooth)、红外线(infrared)端口和串口进行连接(如图4.2所示)。在连接确立之后，这个设备就可以作为Visual Studio的目标了。

在Visual Studio中，您可以配置与真实设备的连接：在“工具”菜单上选择“选项”项。在“选项”对话框中，向下滚动列表，找到“设备工具”节点，将其展开并选择“设备”。选择平台(如Microsoft Windows Mobile 5.0 Pocket PC)，从列表中选择Device(而不是Emulator)，最后，单击“属性”按钮。在“属性”对话框中，单击“配置”按钮打开“配置TCP/IP传输”对话框，如图4.3所示。

图4.2通过ActiveSync 4.5的“文件”菜单打开“连接设置”1

图4.3Visual Studio 2005的设备传输的配置

在默认情况下，通过ActiveSync连接到设备，调试可以轻松进行(如图4.2中的对话框所示)。第一次部署到没有安装.NET Compact Framework的设备上时，框架的二进制代码库会首先推送到目标上，然后才是您的应用程序。要手动在目标上安装.NET Compact Framework，必须将相关的.cab文件(在Visual Studio安装目录的SDK\CompactFramework下)复制到目标机，并在目标机上运行它。根据使用的设备不同，您可能会遇到安全提示。这一般是由于这些二进制代码没有签名所致，确认便可以使其在设备上运行。

基于Microsoft Windows CE的设备不支持ActiveSync，这些系统是定制的，可以遵循如下步骤，使其通过TCP/IP(Transmission Control Protocol/Internet Protocol)直接连接。

1译者注：端口的数目与种类与硬件支持有一定的关系，列表中还可能会包括一些虚拟端口。原书图中只有一个COM3，而译者这里则多了一些；红外线端口也不例外，如果没有安装，它也是不会显示的。

此图为ActiveSync 4.5简体中文版的“连接配置”(原书是4.2版)。

(1) 首先，准备好要连接的设备，从开发计算机上Program Files\Common Files\Microsoft

Shared\CoreCon\1.0\Target\wce400\中复制3个.exe文件和两个.dll文件2到设

备的Windows文件夹下。

(2) 在设备上运行ConmanClient2.exe文件(这是之前所复制的3个可执行文件之一)。

(3) 然后，在“配置TCP/IP传输”对话框(如图4.3所示)，为Visual Studio指定要连接

设备的IP地址。

(4) 如果设备上的安全功能已开启，还需在试图与Visual Studio进行连接之前，运行设

备上的CMAccept.exe。

4.1.2 仿真器

连接到仿真器与通过ActiveSync或WMDC进行连接一样简单。Visual Studio 2005包含一些Windows Mobile 2003 Pocket PC和Smartphone仿真器。若要使用Windows Mobile 5.0的各种仿真器，必须下载免费的软件开发包(SDK)，也可以根据不同情况，下载一些针对某些设备的仿真器镜像(image)。仿真器的发布一般独立于开发环境。可以通过Microsoft下载中心或根据Windows Mobile开发者中心上的链接下载，网址为www.microsoft. com/windowsmobile/developers/default.mspx。对于其他厂商(如Palm)的特殊设备仿真器，可以访问那些厂商的网站来获取。

注意图4.3所示“选项”对话框中的仿真器选项。如果选择其中一项，并单击“属性”按钮，会出现一个类似于图的对话框。您可能会发现对话框中的设置不同，有的提供了另外“DMA传输”。DMA代表“直接存储器访问(Direct Memory Access)”，这是Visual Studio 2005中新的默认传输方式——可以认为它是进程间不通过TCP/IP，而直接进行COM(Component Object Model)通信的技术。不通过TCP/IP，则意味着连接会更快，并且，在没有连接到Internet时，不需要额外的配置(例如，Visual Studio .NET 2003需要配置“环回适配器”)。

可以在运行项目时(如按F5键)选择所要部署的仿真器，也可以通过“选项”对话框(如图4.3所示)、“工具”菜单(选择“连接到设备”)、“项目属性”窗口或通过Visual Studio 的“设备”工具栏进行选择。在图4.4中，您会看到后面两种。

另一个启动仿真器的方式是通过“设备仿真器管理器(Device Emulator Manager)”您可以在“工具”菜单下打开这个工具，如图4.5所示。

2译者注：有的文件夹下是3个。

图4.4通过“项目属性”窗口或“设备”工具栏来选择仿真器

图4.5“设备仿真器管理器”与“工具”菜单(本章会经常提及)3“设备仿真器管理器”的优点之一，是仿真器一旦启动，就可以通过“操作”菜单将其“插入底座”。通过“插入底座”功能，您可以像运行用ActiveSync连接的真实设备那样测试应用程序。还有，插入底座后，仿真器可以通过桌面计算机的Internet连接，连接到Internet上。也可以通过ActiveSync的“浏览”选项打开浏览器窗口，对仿真器中的文件进行读/写。“设备仿真器管理器”的另一个优点是，出于测试或演示的目的，可以单独安装它到一个没有Visual Studio的计算机上。

最后，让我们探究一下仿真器的配置选项。在仿真器的“文件”菜单上，选择“配置”

3译者注：仿真器管理器升级后，界面可能不再为中文的。

打开“仿真程序属性”对话框(如图4.6所示)。“共享文件夹”是一个实用的设置，它可以将桌面计算机上的一个文件夹作为设备上的Stroage Card文件夹，这便可以在桌面计算机中轻松访问设备上的文件了。

图4.6“仿真程序属性”对话框4

通过下载Windows Mobile 6 SDK，您将得到Device Emulator 的第2版，其功能比第1版多。Visual Studio 2008将搭载Device Emulator 第3版。

命令行调试

.NET 2.0的新.NET SDK工具之一，是用于托管应用程序的命令行调试器Mdbg.exe(https://www.360docs.net/doc/eb2552438.html,/en-us/library/ms229861(vs.80).aspx5)。这样便无需在桌面计算机上安装Visual Studio，就可以调试应用程序。.NET Compact Framework 2.0 SP1 中包含Mdbg的扩展MdbgNetcf.dll，您可以用命令行调试设备应用程序。可以通过Mdbg的Load 命令来加载这个扩展，正如前述链接的文档所讲述的。

通过命令行，是对基于Windows CE 4.2目标的托管代码进行调试的唯一方式，因为Visual Studio 2005不再支持那个平台。它还可以在Visual Studio不可用的其他时候下发挥作用。注意，只能通过TCP/IP传输用命令行来调试仿真器，不能通过DMA(可以在“选项”对话框中选择这种传输方式，正如我们本章前面所讨论的那样)。

要了解更多关于命令行调试和其他调试建议与技巧，请访问David Kline的博客，地址为https://www.360docs.net/doc/eb2552438.html,/davidklinems/。

4.1.3 最佳选择

无论部署的是仿真器，还是真实的设备，过程都很简单。那么，哪一种才是设备开发者日常使用的呢？没有正确或错误的答案。如果没有真实设备，显然，仿真器是唯一的选择，而且它会尽职尽责。对于最后的质量保证(QA)测试、用户接受程度测试和交互模式的测试，必须用实际设备来进行(而在仿真器上，没有触笔是不够真实的)。在调试场景下，涉及紧密的硬件交互，一个物理设备或许是最佳的选择(在某些情况下，甚至是必须的)。对性能进行

4译者注：读者若按文中所述打开这个对话框，可能会发现它与这里有一些区别，即某些选项不可用。可以按如下步骤打开这样的窗口：在Visual Studio的“工具”菜单上，打开“选项”窗口，展开“设备工具”，选择要设置的设备，然后单击“属性”按钮，在这个“属性”对话框中，单击“仿真器选项”。

5译者注：简体中文版网址为https://www.360docs.net/doc/eb2552438.html,/zh-cn/library/ms229861(vs.80).aspx。

测试时，您也会经常用到真实设备(有关性能方面的更多探讨，请阅读第5章)。

如果暂时无法获得某些特殊形状的设备，但还要测试，仿真器也会派上用场(例如，不是每个人都有方形的Windows Mobile 5.0 Pocket PC、一个横向的Windows Mobile 5.0 Smartphone或者Windows Mobile 2003 SE Pocket PC的设备)。如果您的目标设备遇到上述的某种情况，那么，仿真器就是一个用于日常开发的不二之选。如果没有您所针对的带有某种自然语言(如希腊语)的设备系统，您可以下载其他的本地化仿真器，可以通过它们来测试应用程序。

最后，一些开发者声称，在真实的设备速度较快(即开发的速度更快，从而节省了开发的时间)。在多数情况下的确如此，但如果在高性能的计算机上运行，并且，有足够大的内存供仿真器使用(更重要的是，如果您已下载并安装最新的高速仿真器)，那些断言也未必总是对的。

4.2 编译时错误

在理想的情况下，代码一旦写好，开发者按动“生成”按钮，计算机就应该找到所有可能的错误。遗撼的是，虽然编译器以可喜的速度日趋完善，已经不只局限于能找出简单的语法错误，但它们仍然不能找出所有可能发生的错误。我们在接下来的几节中将讨论运行时错误。因为它们不易被识别和更正，所以要充分利用编译器的功能，使其做尽可能多的工作。

排除错误 编译器会将错误和警告显示在“错误列表”对话框中，此对话框可以在Visual Studio 2005的“查看”菜单下打开。应总是从错误和警告列表的最上端开始查

找。您可以双击其描述导航到所对应的文件，并精确定位到发生问题的那一行。

也可以用右键单击那一项，并选择“显示错误帮助”来获得更多内建的帮助信息。

最后，可以使用您所偏爱的搜索引擎搜索确切的错误描述(用双引号引上)，它会

返回问题的讨论结果。换言之，通过不同方法，在短期内就可以找到有关编译错

误的信息。

利用编译时诊断的技巧之一是，除了错误以外，还应检查一下“错误列表”中的警告(如图4.7所示)。

图4.7“错误列表”对话框

在“项目属性”窗口(可以在“项目”菜单中打开)中的“生成”选项卡上，将“警告等级”设置为4。等级1是编译器基本上能确定的错误，且其在语法和语义上是正确的。等级4警告的情况是初学者可能会犯的一些错误，编译器只能确保开发者得到通知。等级2和等级3的警告介于两种极端情况之间。6

在Microsoft Visual Basic项目中，对应的是“编译”选项卡，其中的列表包含9个条件，每一个都对应一种通知项，其行为可以更改。我们强烈建议将前三个和最后5个条件配置为“错误”，如图4.8所示。

图4.8Visual Basic“项目属性”窗口中的“编译”选项卡

如果您的Visual Basic“项目属性”窗口与图4.8有出入，表明您放弃在编译时捕捉错误的机会，而将会潜在的错误推迟到运行时来处理，这样，诊断通常会更困难。

可以将第4个条件(在赋值前使用变量)设置成“警告”，但它可能会产生很多虚假断言，而并不会有实质性的帮助。因为这个功能没能正确无误地涵盖所有可能的条件，所以，同样，它只是有时会有所帮助，而不会总是。然而，还是应该相信，有一天它能够完善！如果您决

6译者注：等级0，关闭所有警告消息的显示；等级1，显示严重的警告消息；等级2，显示等级1 警告以及某些不太严重的警告；等级3，显示等级2 警告以及某些不太严重的警告；等级4，显示所有等级3 警告以及信息性警告。

定将这个条件设置成“警告”或“错误”，那就看看下面的例子，它演示了虚假断言的出现：Public Sub FalsePositive1()

Dim s As String

s = s & "why?" ' WARNING ?! - it is a valid statement

End Sub

Public Sub FalsePositive2()

Dim o As Collection

' some other code here

If o Is Nothing Then ' WARNING ?! - just checking if it is null o = New Collection()

End If

End Sub

Public Sub FalsePositive3()

Dim s As Object

Me.GetValueByRef(s) ' WARNING ?!

' I don't want to initialize s. The function will.

End Sub

' If only Visual Basic had "out" like C# has

Private Function GetValueByRef(ByRef methodAssignIt As Object) As Boolean methodAssignIt = "some value to return"

Return True

End Function

如果您拥有Visual Studio 2005 Team Edition版本之一，可以利用另外的编译时工具“代码分析”(Code Analysis)(曾被称作FxCop)。在“项目属性”窗口中的“代码分析”选项卡，选择“启用代码分析”复选框。这将生成其他警告消息，帮助您提高所写代码的质量。例如，给出下面这段代码：

public class MyType

{

public int NoOfWidgets; // CA1051

public void DoSomething()

{

string s = "start";

for (int i = 0; i < 30; i++)

{

s += "let's kill perf"; //CA1818

}

}

}

您至少得到两个警告：

(1) CA1818：Microsoft.Performance：将MyType.DoSomething():Void 更改为使用

StringBuilder 而不使用String.Concat 或+=。

(2) CA1051：Microsoft.Design：将“NoOfWidgets”标记为private 或internal (在VB

中为Friend，在C++ 中为public private)，并提供public 或protected 属性来访

问它。

不幸的是，这些警告没有针对智能设备项目特别设计，一些警告或许并不恰当，而仅当所写的代码用于桌面平台的完整版.NET Framework才较为合适。事实上，即使在完整版.NET Framework项目中，也不要苛求消除所有FxCop的警告消息，因为它们可能不总是符合您特殊的目的。话虽如此，在智能设备项目中还是能在“代码分析”中找到有价值的信息，所以，将这个功能开启(即便偶尔会有用)，在您将代码提交到QA小组之前，也不妨一试。

技巧 要禁用FxCop对某个方法、类，甚至是程序集的警告消息，您可以使用System.

Diagnostics.CodeAnalysis.SuppressMessageAttribute。右键单击警告消息，并选择“禁

止显示消息”，可以自动插入这个属性。也可以通过“项目属性”窗口，将特定警告更改为错误7。

4.3 异常处理——与完整版.NET Framework一致

遵照前一节的建议，编译器在程序运行之前排错功能就几乎发挥到了极致。然而，没有哪个应用程序没有问题和错误，通过以下两种方式表现出来。

●逻辑错误，它将导致程序产生错误的结果和/或行为(这将在本章后面讨论)。

●运行时抛出的异常。

我们在接下来的几节中，将讨论各类运行时异常，并讲解如何进行处理，但在此之前，我们还是先来讨论一些针对.NET的异常处理。

从根本上说，.NET Compact Framework的错误处理与完整版.NET Framework的一致。异常用于不可预知的情况，而不能用于控制正常的通信流(用返回值或事件来代替，会是一个更理想、更快速地方式)。异常的抛出与捕获也使用人们熟知的throw，try，catch和finally 结构。在Visual Basic中，还可以使用关键字when，它甚至还延续了对On Error GoTo/Resume Next的支持，但这并不意味着应该使用它们。这个建议与桌面上的一致，其中一个原因是出于对性能的考虑。某些功能若在桌面上对性能造成消极影响，同样会在移动设备上发生。要进一步了解性能，请阅读第5章。

当一个异常被抛出时，它会在调用堆栈(call stack)中逐方法传递。其中每个方法都有机会在catch代码块中捕获并处理这个异常，要么不予理会，继续传递下去(bubble up)，要么重新抛出(rethrow)，如下面这段代码所示(虽然不太切合实际)：

private void SomeMethod()

{

// 1. There is no try..catch around this call, so if an

// exception is thrown inside MethodThatMayThrow(),

// let it bubble up to be handled by some method higher

// up the call stack.

this.MethodThatMayThrow();

// 2. Rethrow.

try

{

this.MethodThatMayThrow();

}

catch (Exception ex)

{

// Do something with the exception object, such as log it.

LogException(ex);

// or do something else such as cleanup in this code block,

DoCleanup();

// now rethrow to allow this exception to be handled elsewhere.

throw;

}

// 3. Catch exception.

try

{

this.MethodThatMayThrow();

}

catch (Exception ex)

{

// FULLY deal with this exception.

7译者注：在“代码分析”选项卡中，通过单击“状态”列的警告图标，或双击“警告”或“错误”标签来切换这两种状态。

RunSomeCodeSpecificToThisException();

}

// 4. Swallow.

try

{

this.MethodThatMayThrow();

}

catch (Exception ex)

{

// Swallow, just so it doesn't go up to other methods.

// DO NOT do this!

}

}

桌面上的优秀异常处理技术，也可以应用于设备开发。永远不要“吞噬”8异常！当异常在运行时发生后，它会提供所有用于修正错误的信息：消息、类型和调用堆栈。若吞噬了异常，您就等于对所有这些信息置之不理。只是简单捕获异常，而不对此做任何处理，会导致严重的错误且很难诊断。即使程序吞噬异常后运行良好，但也可能由于掩盖错误积累而导致程序执行的失败，且无法追溯到错误的根源。

提示 捕获异常并决定再次抛出它时，应该使用“throw;”语句而不是“throw ex;”。前者会保护调用堆栈，后者会对其进行重置，这会导致重要信息的丢失。本章的代码遵循了这条规范，它也可以为您的代码提供一个好的范例。

另一个好习惯是，捕获特定的异常。这不像4.2节示例代码所做的那样，在调用代码时，有必要了解一下可能会发生的异常类型，并在catch块中明确地进行指定，例如：private void UpdateTimer(ref System.Threading.Timer tmr)

{

try

{

tmr.Change(2000, 10000);

}

catch (ObjectDisposedException)

{

tmr = new System.Threading.Timer(…);

tmr.Change(2000, 10000);

}

}

要捕获泛化Exception对象的唯一理由，可能是再重新将其抛出之前，进行一些操作，也可能是由于您所调用的代码没有在文档中注明它所抛出的异常类型。即使是后一种情况，如果要在主调代码中处理Exception类型的异常，应确保它能够真正处理所抛出的“各种”类型的异常！当然，try块可以不仅可以有一个与其对应的catch块，在这种情况下，一般用最后一个catch块处理泛化的Exception类型，做一些清理工作，然后重新将其抛出(而第一个catch块必须处理最有针对性的异常)。

警告 在.NET Compact Framework中，某些情况生成的异常类型，与相同情况下完整版.NET Framework不一致(这与某些在线文档稍微有些冲突)。例如，以下代码段在.NET Compact Framework框架中引发的是InvalidOperationException异常，而在桌面上会导致TargetInvocationException异常(其InnerException属性会被设置成InvalidOperationException)。

private void button2_Click(object sender, EventArgs e)

{

Type t = this.GetType();

MethodInfo m = t.GetMethod("DoIt");

8译者注：见前面代码中的“4. Swallow”。

m.Invoke(this, null);

}

public void DoIt()

{

throw new InvalidOperationException("my msg");

}

警告 这种设计将导致使用范围的限制。当您的代码需要使用相同的基本代码库来跨越多个平台时，这个问题会更加突出。您必须能够捕获那两种类型的异常，以便代码会按照预想的那样，正确地在两个平台上运行。

前面提到过清理的问题。这不应与finally代码块混淆。在前面几部分中，清理所涉及的代码仅运行于异常被抛出时，而放在finally块中的代码总会运行，不管是否发生异常。桌面世界的忠告在此同样适用：在程序中，try..finally块在数量上应比try..catch块多。换句话说，仅在处理异常时才捕获它，同时，不论发生的是不可预知的异常，还是没有捕获到的异常，都要确保清理代码能够被执行。

截止到目前，我们已经回顾了.NET中的异常处理结构，并给出了一些忠告，现在是详细讨论运行时异常的时候了。

4.4 运行时异常

如果某个异常没有被捕捉并处理，您将最终在运行时得到一个未处理异常。图4.9所示为最终用户在Pocket PC上看到的界面。

(a) (b)

图4.9内建的用于显示运行时未处理异常对话框：退出程序的选项(a)；单击“详细信息”后的结果(b)

在本章前面提出了一条规则：永远不要“吞噬”异常。那么第二条规则是：永远也不要让用户看到运行时异常。在接下来的几节中，将讨论下面几个问题来细化这条规则：

●如何调试并找到所发生的异常

●为什么未处理异常是开发者的失误

●如何从根本上避免异常被抛出

●如果不可避免引发异常，应该如何处理

●全局异常处理(最后的防线)

如果您注意到本章前面给出的忠告“永远不要吞噬异常”，那便很容易推理出这一结论：

永远不要有未处理的运行时异常。

4.4.1 异常起因的诊断

虽然不要让用户看到运行时异常(正如下一节要讨论的)，但一般的开发者还是愿意在调试或测试时发现少量异常。

一般情况下，开发者编写代码后，确认其可以被编译，然后按F5键(或选择“调试”菜单下的“启动调试”)启动Visual Studio的调试器并运行项目。当代码在目标上运行时，如果某个异常被抛出，调试器将会暂停于Visual Studio的代码文件上，并定位在引发异常的那一行。例如，如果您注意以下代码段第二行中的NullReferenceException，不难看出，它忘记了对obj进行初始化，更正很简单(如obj = new SomeClass();)：

…

SomeType obj = null;

obj.SomeMethod(); // NullReferenceException

…

这里有另外一个例子。以下代码会引发InvalidCastException，调试器将停留在出现问题的那一行(如图4.10所示)：

private void AnotherMethod(SomeClass obj)

{

((ISomeInterface)obj).DoIt();

}

图4.10 调试器提示一个未处理异常，直逼异常发生的那一行

通过异常的名称和那行代码，一般就能猜测到问题所在。但某些情况下，还是需要进一步进行研究。例如，在之前的示例代码中，您可能会猜测SomeClass没有实现IsomeInterface 接口。基于这种假设，那些代码可以像下面这样改写，但仍然会抛出异常：private void AnotherMethod(SomeClass obj)

{

ISomeInterface i = obj as ISomeInterface;

if (i != null)

{

i.DoIt(); // still throws here!

}

else

{

// Do something else!

}

}

同样的异常还会出现在原来那一行，但要清楚，异常事实上来自更深处，而在这里，就是DoIt方法本身。

技巧 将多行代码连接成一行是不明智的，而且还会使可调试性降低。最好将其分解为多行，除了缓解上述问题，还会增强代码的可读性。

DoIt方法和SomeClass类型位于扩展的类库中，因而，调试器停在调用它的位置上。然而，(暂时不更改代码)您可能通过查看调用堆栈已经注意到，在“调用堆栈”对话框(如图4.11所示)，其所停在的位置，比第一个示例继续前进了一步。

图4.11“调用堆栈”窗口在调试时十分有用

注意此程序和其他类库中不可用的代码在调用堆栈中是如何显示的。在调用堆栈的顶端，很容易定位到DoIt方法(异常发生源头)。

技巧 注意图4.11中其他窗口是如何辅助调试的。可以在Visual Studio 的“查看”和“调试”菜单下打开它们。对各自的功用描述，不在本书的讨论范围之列，但我们推荐您通过阅读Visual Studio文档进行学习。

如果在没有调试器的情况下运行程序(如直接运行.exe文件)，在设备上也可以找到调用堆栈。如果您在目标上运行程序，用户所看到的用于显示未处理异常的内建错误对话框，有一个“详细信息”按钮。单击这个“详细信息”按钮即可显示调用堆栈(如图4.12所示)。

(a) (b) (c)

图4.12内建的用于显示未处理异常错误对话框：“详细信息”视图显示了调用堆栈——虽然对最终用户毫无用处，但对于开发者来说，在调试时是非常有用的在.NET Compact Framework 2.0版中，可以通过Exception类的StackTrace属性以编码方式使用调用堆栈。如果像下面这样更改代码，便会在“输出”窗口中显示调用堆栈(见

图4.13)：

private void AnotherMethod(SomeClass obj)

{

try

{

((ISomeInterface)obj).DoIt();

}

catch (InvalidCastException ex)

{

// Log the exception to file.

Debug.WriteLine("The stacktrace: \r\n" + ex.StackTrace);

// Take some real recovery action!

}

}

图4.13Exception.StackTrace会返回一个字符串，并被打印到“输出”窗口

4.4.2 这是您的失误

了解如何找到异常根源后，您可能会问：为什么会发生未处理的运行时异常？事实上，发生未处理的运行时异常是程序员的失误(虽然这会有争议)。尽管有CLR(common language runtime，公共语言运行库)的致命性异常(如OutOfMemoryException，StackOverflowException 或ExecutionEngineException)，但开发者还是可以通过的代码避免其他异常的抛出，或至少能够优雅地处理这些异常。

异常什么时候发生？答案很明显，但还是要强调一下，看过前一段的代码就不难理解。异常的发生是由于所编写的语句，一般是方法的调用。在调用方法前，您要了解此方法所能抛出的各种不同的异常，您还要知道，它为什么会被抛出。要了解这些，既可以通过文档(可能是来自Microsoft或者是第三方的)，也可以通过所写的方法(记得将它可能抛出的异常整理成文档)。即使某些方法没有完全文档化，在测试时，也要对方法做出注释，以便易于发现它可能抛出的异常。这样就能在调用的地方来处理它们。若在部署后发现一个未知类型的异常，只说明您的测试还进行得不够彻底。查看您在代码中所写的每一条语句，并问这样一个问题：“这行代码会引发异常吗？”如果答案是肯定的，再继续考虑如何避免此异常的发生。

4.4.3 避免异常抛出

考虑下面的代码示例：

private void DoSomethinginterestingWith(string path)

{

FileStream fs = File.Open(path, FileMode.Open);

// Do something interesting with fs.

}

此代码做了一个假设，而这个假设将导致异常的发生。此代码假设在给定的路径中确实有那么一个文件。事实上，如果无法确定，您可以从它的文档中取得帮助。其中将列出可能抛出的各种异常，其中之一是FileNotFoundException。一个既幼稚又错误的方式是像下面这样更改代码：

private void DoSomethinginterestingWith(string path)

{

try

{

FileStream fs = File.Open(path, FileMode.Open);

// Do something interesting with fs.

}

catch (FileNotFoundException ex)

{

// TODO deal with the invalid input

}

}

这的确会捕捉异常，并处理。然而，通过正确的方式来编写语句，完全可以避免这个异常，如下所示：

private void DoSomethinginterestingWith(string path)

{

if (File.Exists(path))

{

FileStream fs = File.Open(path, FileMode.Open);

// Do something interesting with fs.

}

else

{

// TODO deal with the invalid input

}

}

前面这个模式非常普遍。大多数情况下，您可以通过if语句来替代try..catch，这也是第一道防线。回忆一下便知道，前一节的代码示例要避免的是InvalidCastException。

4.4.4 合理进行异常处理与恢复

当然，在某些场景中，不可能以那种方式避免来自所调用方法的异常。在那种情况下，可以做出一个选择：不能处理某个异常时，是让它继续向堆栈上方传递，还是就地处理它。在本节开始时，有一个例子处理的是Timer所抛出的ObjectDisposedException异常。在下面，您还会看到一些相关的例子。

您可以通过将某个异常转换为一种对状态的改变来处理这个异常。以下代码段展示了这个方法如何引发特定异常条件下的自定义事件，并在让它继续向上传递前，将这个未处理异常记入日志：

private void ConnectToThis(IPEndPoint ep)

{

Socket s = new Socket(AddressFamily.InterNetwork,

SocketType.Stream, ProtocolType.Tcp);

try

{

s.Connect(ep);

}

catch (SocketException)

{

// Translate exception to own custom event.

if (CantConnect != null)

CantConnect(this, EventArgs.Empty);

}

catch (ArgumentNullException)

{

// IPEndPoint passed in is null. Pass it up, caller's fault.

throw;

}

catch (Exception ex)

{

LogException(ex); //our own logging method

throw;

}

}

另一种处理上述异常的方式是使用一个返回结果：

private bool ConnectToThis2(IPEndPoint ep)

{

Socket s = new Socket(AddressFamily.InterNetwork,

SocketType.Stream, ProtocolType.Tcp);

try

{

s.Connect(ep);

return true;

}

catch (SocketException)

{

// Translate exception to return result.

return false;

}

……

}

在第一个例子中，异常被转换成某种状态的改变，这次是通过返回值来通知主调代码。原则还是一样的：永远也不要吞噬异常——要么完全处理，要么将其向上传递到其他方法中，这样，其他方法也有机会处理或者使其继续向上传递。

让异常继续向上传递的一个变种方法是，在捕获它的那一层中，将其封装为另一种异常并抛出。要让主调代码抛出一个更有意义的异常时，将现有异常封装成另一个的方式非常有效。在这种情况下，您可以使用其他框架中更有针对性的异常，或者，创建一个自定义的。

在前面有关套接字(socket)的示例中，若不想将异常转换成状态，可以选择抛出自己的异常CantConnectException，而不是让SocketException继续向上传递，如下所示：private void ConnectToThis3(IPEndPoint ep)

{

Socket s = new Socket(AddressFamily.InterNetwork,

SocketType.Stream, ProtocolType.Tcp);

try

{

s.Connect(ep);

}

catch (SocketException ex)

{

// Wrap existing exception with more descriptive one.

throw new CantConnectException(ex); //Nest the existing exception.

}

… …

}

始终牢记，异常不能替代事件和返回值在方法间进行通信。实在没有可行的处理方法时，才能抛出异常(现有的或自定义的)。当您确定抛出异常是一个正确的选择，但不能确定是抛出现有异常时，还是自定义异常时，就抛出现有异常时。

4.4.5 保卫边界(全局异常处理：最后的防线)

通过检查代码中的语句和方法调用，您可以避免异常的发生(即使用条件判断)，否则，要么彻底处理它们(即将.NET异常转换为您业务逻辑中的状态)，要么使其继续向上传递。如果将它一直沿着调用堆栈向上传递，而没有哪个方法去处理它，最后结果如何？最后的结果就是用户可以看到未处理的异常，这正是您要避免的。遵循本章中的指导原则，可以确保用户不会看到未处理异常。

某些在“保卫边界”方面的方法很特殊。边界方法(boundary method)是调用堆栈中根部的后备方法。

●GUI(graphical user interface)控件的事件处理程序(如按钮的单击)。它们保护着UI

边界。换句话说，它们是主UI线程的入口点。任何脱离其中的异常(即向上传递以

致逾越调用堆栈顶端的)都会在内建的错误对话框中显示出来。

●线程上第一个运行的方法。任何脱离第一个线程方法的异常会在内建的错误对话框

中显示出来。

●用于对您的应用程序进行输入的扩展类库事件处理程序。如果您需处理来自第三方

类库的事件并抛出异常，这个异常将沿着调用堆栈传递到那个类库的根方法。这样，它会被如何处理，就不由我们决定了——不应该使其逃出您的边界。

边界方法的特殊有两个原因。其一，它不允许任何异常继续沿堆栈向上传递，因为接下来的一层就是最终用户。因而，要注意每一个符合前述条件的方法，并使用try..catch语句对其进行封装。在catch块中，因为那可能是完全不可预知的，所以，要记录所发生的异常，通知用户，并以友好方式退出程序。在极少数情况下，对于个别的GUI事件处理的方法，要判断它是否会对整个程序运行的安全造成威胁。换句话说，要判断程序是否处在一个不确定状态下，并判断是否需要为此而退出。注意，即使边界方法通过try..catch封装整个方法体，也并不意味着其内部就不应该再有try..catch块来封装可能抛出特定异常的方法。总而言之，边界方法是捕获错误的安全之网，也是处理异常的最后场所。

这些方法特殊的第二个原因是，它们必须防止程序的其他部分接收到非法输入。这就要求在执行逻辑代码前，验证每一处输入。如果某些非法输入侵入到某个先行的方法中，则不要再去调用其他内部方法。如果这个输入是用户的行为(例如，在一个文本框中进行非法的输入)，那就提示他。

那么，再考虑一下前面例子中的Socket.Connect。这次，来看一下对ConnectToThis方法调用(假设它来自某个菜单的单击)：

private void menuItem2_Click(object sender, EventArgs e)

{

IPAddress ipAddress = this.GetIpAddressSomehow();

int port;

port = Convert.ToInt32(textBox1.Text);

IPEndPoint ipe = new IPEndPoint(ipAddress, port);

this.ConnectToThis(ipe);

}

这是一个边界方法，基于之前的忠告，不应允许任何异常向上传递。在分析过此方法之后，可以像下面这样进行改进：

private void menuItem2_Click(object sender, EventArgs e)

{

IPAddress ipAddress = this.GetIpAddressSomehow();

if (ipAddress == null)

{

MessageBox.Show("Sorry could not get ip address.");

return;

}

int port;

try

{

port = Convert.ToInt32(textBox1.Text);

}

catch (FormatException)

{

MessageBox.Show("Please provide a valid port number.");

return;

}

IPEndPoint ipe = new IPEndPoint(ipAddress, port);

try

{

this.ConnectToThis(ipe);

}

catch (CantConnectException ex)

{

MessageBox.Show("Sorry, could not connect");

}

}

注意，除了“由于它是边界方法，不应让它允许任何异常向上传递”，本章目前所给出

的所有忠告，在此都已一一应用。

由于它是边界方法，那么最后一项任务是，防备您自己所犯的错误或对边界方法与调用分析出现遗漏。(请先有个印象，因为我们会在本章4.5节继续这个话题。)这意味着，需要捕获所有不可预知的异常：

private void menuItem2_Click(object sender, EventArgs e)

{

try

{

IPAddress ipAddress = this.GetIpAddressSomehow();

if (ipAddress == null)

{

MessageBox.Show("Sorry could not get ip address.");

return;

}

int port;

try

{

port = Convert.ToInt32(textBox1.Text);

}

catch (FormatException)

{

MessageBox.Show("Please provide a valid port number.");

return;

}

IPEndPoint ipe = new IPEndPoint(ipAddress, port);

try

{

this.ConnectToThis(ipe);

}

catch (CantConnectException ex)

{

MessageBox.Show("Sorry, could not connect");

}

}

catch (Exception ex)

{

LogException(ex);

MessageBox.Show(

"An unexpected error has occured. Please shut down this app.");

ExitApplication();

}

}

您会发现，如果将这些措施实施到每一个边界方法，没有哪一个异常能逃脱应用程序。

注意 对于类库来说，边界方法的定义牵涉所有公共类的公共方法(即类库的入口点)。这些规范同样适用，除了通知用户，并/或退出应用程序，还要为其外部的调用者抛出一个合理的异常。作为类库开发者，请记住，应将所有离开您所管辖范围的异常记录在日志中。

4.5 全局异常处理

.NET Compact Framework团队强烈要求实现的功能之一是能在一处捕获全局未处理异常。这已经在完整版.NET Framework中实现了，而在.NET Compact Framework 1.0版中并不