CSDN博客

img rainbow

<<展现C#>> 第七章 异常处理(修订)

发表于2000/9/5 10:57:00  1051人阅读

     第七章   异常处理

 

    通用语言运行时(CLR)具有的一个很大的优势为异常处理是跨语言被标准化的。一个在C#中所引发的异常可以在Visual Basic客户中得到处理。不再有 HRESULTs  或者 ISupportErrorInfo 接口。

    尽管跨语言异常处理的覆盖面很广,但这一章完全集中讨论C#异常处理。你稍为改变编译器的溢出处理行为,接着有趣的事情就开始了:你处理了该异常。要增加更多的手段,随后引发你所创建的异常。

 

7.1  检查和非检查语句(checked and unchecked statements)

    当你执行运算时,有可能会发生计算结果超出结果变量数据类型的有效范围。这种情况被称为溢出,依据不同的编程语言,你将被以某种方式通知——或者根本就没有被通知。(C++程序员听起来熟悉吗?)

     那么,C#如何处理溢出的呢? 要找出其默认行为,请看我在这本书前面提到的阶乘的例子。(为了方便其见,前面的例子再次在清单 7.1 中给出)

 

清单 7.1     计算一个数的阶乘

 

 1: using System;

 2:

 3: class Factorial

 4: {

 5:  public static void Main(string[] args)

 6:  {

 7:   long nFactorial = 1;

 8:   long nComputeTo = Int64.Parse(args[0]);

 9:

10:   long nCurDig = 1;

11:   for (nCurDig=1;nCurDig <= nComputeTo; nCurDig++)

12:    nFactorial *= nCurDig;

13:

14:   Console.WriteLine("{0}! is {1}",nComputeTo, nFactorial);

15:  }

16: }

 

    当你象这样使用命令行执行程序时

    factorial 2000

 

    结果为0,什么也没有发生。因此,假定C#默默地处理溢出情况而不明确地警告你是安全的。

     通过对整个应用程序(经编译器开关)或在语句级允许溢出检查,你就可以改变这种行为。以下两节分别解决一种方案。

7.1.1溢出检查的编译器设置

    如果你想控制整个应用程序的溢出检查,C#编译器设置选项正是你所要找的。默认地,溢出检查是禁用的。要明确地请求它,运行以下编译器命令:

csc factorial.cs /checked+

 

    现在当你用2000参数执行应用程序时,CLR通知你溢出异常(见图 7.1)。

 

7.1 允许了溢出异常,阶乘代码产生了一个异常。

 

 

 

  按确定键离开对话框出现了异常信息:

Exception occurred: System.OverflowException

  at Factorial.Main(System.String[])

 

  现在你了解了溢出条件引发了一个 System.OverflowException异常。下一节,在我们完成语法检查之后,如何捕获并处理所出现的异常?

7.1.2 语法溢出检查

  如果你不想对整个应用程序进行溢出检查,那么只允许对某些代码段进行检查便可,这样可能会很顺畅。在这种场合下,你可能象清单7.2中显示的那样使用检查语句。

 

清单 7.2  阶乘计算中的溢出检查

 

 1: using System;

 2:

 3: class Factorial

 4: {

 5:  public static void Main(string[] args)

 6:  {

 7:   long nFactorial = 1;

 8:   long nComputeTo = Int64.Parse(args[0]);

 9:

10:   long nCurDig = 1;

11:

12:   for (nCurDig=1;nCurDig <= nComputeTo; nCurDig++)

13:    checked { nFactorial *= nCurDig; }

14:

15:   Console.WriteLine("{0}! is {1}",nComputeTo, nFactorial);

16:  }

17: }

 

  纵使你运用标志 checked- 编译了该代码,在第13行中,溢出检查仍然会对乘法实施检查,因为checked 语句已经括住了它。将会出现相同的错误信息。

  显示相反行为的语句是unchecked 。甚至如果允许了溢出检查(给编译器加上checked+标志),被unchecked 语句所括住的代码也将不会引发溢出异常:

 

unchecked

{

 nFactorial *= nCurDig;

}

 

7.2  异常处理语句

  既然你知道了如何产生一个异常(你会发现更多的方法,相信我),仍然存在如何处理它的问题。如果你是一个 C++ WIN32 程序员,肯定熟悉SEH(结构异常处理)。令人感到欣慰的是,C#中的命令几乎是相同的,而且它们也以相似的方式运作。

 

以下三节介绍了C#的异常处理语句:

。用 try-catch 捕获异常

。用try-finally 清除异常

。用try-catch-finally 处理所有的异常

 

7.2.1  使用 try catch捕获异常

  你肯定会对一件事非常感兴趣——不要给用户提示那些令人讨厌的异常消息,以便你的应用程序继续执行。要这样,你必须捕获(处理)该异常。

要用到的语句是try catchtry包含可能会产生异常的语句,而catch处理一个异常,如果有异常存在的话。清单7.3 try catchOverflowException 实现异常处理。

 

清单7.3  捕获由   Factorial Calculation引发的OverflowException 异常

 

 1: using System;

 2:

 3: class Factorial

 4: {

 5:  public static void Main(string[] args)

 6:  {

 7:   long nFactorial = 1, nCurDig=1;

 8:   long nComputeTo = Int64.Parse(args[0]);

 9:

10:   try

11:   {

12:    checked

13:    {

14:     for (;nCurDig <= nComputeTo; nCurDig++)

15:      nFactorial *= nCurDig;

16:    }

17:   }

18:   catch (OverflowException oe)

19:   {

20:    Console.WriteLine("Computing {0} caused an overflow exception", nComputeTo);

21:    return;

22:   }

23:

24:   Console.WriteLine("{0}! is {1}",nComputeTo, nFactorial);

25:  }

26: }

 

为了说明清楚,我扩展了某些代码段,而且我也保证异常是由checked 语句产生的,甚至当你忘记了编译器设置时。

正如你所见,异常处理并不麻烦。你所有要做的是:在try语句中包含容易产生异常的代码,接着捕获异常,该异常在这个例子中是OverflowException类型。无论一个异常什么时候被引发,在catch段里的代码会注意进行适当的处理。

如果你不事先知道哪一种异常会被预期,而仍然想处于安全状态,简单地忽略异常的类型。

 

try

{

...

}

catch

{

...

}

 

但是,通过这个途径,你不能获得对异常对象的访问,而该对象含有重要的出错信息。一般化异常处理代码象这样:

 

try

{

...

}

catch(System.Exception e)

{

...

}

 

注意,你不能用 ref  out 修饰符传递 e 对象给一个方法,也不能赋于它一个不同的值。

 

7.2.2  使用 try finally 清除异常

如果你更关心清除而不是错误处理, try  finally 会获得你的喜欢。尽管它并没有抑制出错信息,但包含在 finally 块中的代码在异常被引发后仍然会被执行。

尽管程序不正常终止,但你还可以给用户提供一条消息,如清单 7.4 所示。

 

清单 7.4  finally 语句中处理异常

 

 1: using System;

 2:

 3: class Factorial

 4: {

 5:  public static void Main(string[] args)

 6:  {

 7:   long nFactorial = 1, nCurDig=1;

 8:   long nComputeTo = Int64.Parse(args[0]);

 9:   bool bAllFine = false;

10:

11:   try

12:   {

13:    checked

14:    {

15:     for (;nCurDig <= nComputeTo; nCurDig++)

16:      nFactorial *= nCurDig;

17:    }

18:    bAllFine = true;

19:   }

20:   finally

21:   {

22:    if (!bAllFine)

23:     Console.WriteLine("Computing {0} caused an overflow exception", nComputeTo);

24:    else

25:     Console.WriteLine("{0}! is {1}",nComputeTo, nFactorial);

26:   }

27:  }

28: }

 

通过测试该代码,你可能会猜到,即使没有引发异常处理,finally也会被执行。这是真的——在finally中的代码总是会被执行的,不管是否具有异常条件。为了举例说明如何在两种情况下提供一些有意义的信息给用户, 我引进了新变量bAllFinebAllFine告诉finally 语块,它是否因为一个异常或者仅是因为计算的顺利完成而被调用。

作为一个习惯了SEH程序员,你可能会想,是否有一个与C++中很管用的__leave 语句等价的语句。如果你还不了解,这里说明一下:在C++中的__leave 语句是用来提前终止 try  语段中的执行代码,并立即跳转到finally 语段

坏消息! C# 中并没有__leave 语句。但是,在清单 7.5 中的代码演示了一个你可以实现的方案。

 

清单 7.5  try语句 跳转到finally 语句

 

 1: using System;

 2:

 3: class JumpTest

 4: {

 5:  public static void Main()

 6:  {

 7:   try

 8:   {

 9:    Console.WriteLine("try");

10:    goto __leave;

11:   }

12:   finally

13:   {

14:    Console.WriteLine("finally");

15:   }

16:

17:   __leave:

18:   Console.WriteLine("__leave");

19:  }

20: }

 

 

当这个应用程序运行时,输出结果为

 

try

finally

__leave

 

一个 goto 语句不能退出 一个finally 语块。甚至把 goto 语句放在 try 语句块中,还是会立即返回控制到 finally 语块。因此,goto 只是离开了 try 语块并跳转到finally 语块。直到 finally 中的代码完成运行后,才能到达__leave 标签。按这种方式,你可以模仿在SEH中使用的的__leave 语句。

顺便地,你可能怀疑goto 语句被忽略了,因为它是try 语句中的最后一条语句,并且控制自动地转移到了 finally 。为了证明不是这样,试把goto 语句放到Console.WriteLine 方法调用之前。尽管由于存在着不可到达代码,使你得到了编译器的警告,但是你将看到goto语句实际上被执行了,而没有产生“try”字符串的输出。

 

7.2.3  使用try-catch-finally处理所有异常

应用程序最有可能的途径是合并前面两种错误处理技术——捕获错误、清除并继续执行应用程序。所有你要做的是在出错处理代码中使用 try catch finally语句。清单 7.6 显示了处理零除错误的途径。

 

清单 7.6  实现多个catch 语句

 

 1: using System;

 2:

 3: class CatchIT

 4: {

 5:  public static void Main()

 6:  {

 7:   try

 8:   {

 9:    int nTheZero = 0;

10:    int nResult = 10 / nTheZero;

11:   }

12:   catch(DivideByZeroException divEx)

13:   {

14:    Console.WriteLine("divide by zero occurred!");

15:   }

16:   catch(Exception Ex)

17:   {

18:    Console.WriteLine("some other exception");

19:   }

20:   finally

21:   {

22:   }

23:  }

24: }

 

这个例子的技巧为,它包含了多个catch 语句。第一个捕获了更可能出现的DivideByZeroException异常,而第二个catch语句通过捕获普通异常处理了所有剩下来的异常。

你肯定总是首先捕获特定的异常,接着是普通的异常。如果你不按这个顺序捕获异常,会发生什么事呢?清单7.7中的代码有说明。

 

清单7.7   顺序不适当的 catch 语句

 

 1:   try

 2:   {

 3:    int nTheZero = 0;

 4:    int nResult = 10 / nTheZero;

 5:   }

 6:   catch(Exception Ex)

 7:   {

 8:    Console.WriteLine("exception " + Ex.ToString());

 9:   }

10:   catch(DivideByZeroException divEx)

11:   {

12:    Console.WriteLine("never going to see that");

13:   }

 

 

    编译器将捕获到一个小错误,并类似这样报告该错误:

wrongcatch.cs(10,9): error CS0160: A previous catch clause already

catches all exceptions of this or a super type ('System.Exception')

 

意思为:

wrongcatch.cs(10,9): 错误代码 CS0160: 前面的catch语句早已捕获了这个或高级类型('System.Exception')的所有异常。

 

最后,我必须报导CLR异常与SEH相比时的一个缺点(或差别):没有在SEH异常过滤器中很有用的EXCEPTION_CONTINUE_EXECUTION标识符的等价物。基本上,EXCEPTION_CONTINUE_EXECUTION 允许你重新执行负责异常的代码片段。在重新执行之前,你有机会更改变量等。我个人特别喜欢的技术为:通过使用存取违例异常,按需要实施内存分配。

  

7.3  引发异常

当你不得不捕获异常时,其他人首先必须首先能够引发异常。而且,不仅其他人能够引发,你也可以负责引发。其相当简单:

throw new ArgumentException("Argument can't be 5");

你所需要的是throw 语句和一个适合的异常类。我已经从表7.1提供的清单中为这个例子选出一个异常。

 

7.1      Runtime提供的标准异常

异常类型  

描述

Exception

所有异常对象的基类

SystemException

运行时产生的所有错误的基类

IndexOutOfRangeException

当一个数组的下标超出范围时在运行时被引发

NullReferenceException

当一个空对象被引用时在运行时被引发

InvalidOperationException

当对方法的调用对对象的当前状态无效时,由某些方法引发

ArgumentException

所有参数异常的基类

ArgumentNullException

在参数为空(不允许)的情况下,由方法引发。

ArgumentOutOfRangeException

当参数不在一个给定范围之内时,由方法引发

InteropException

目标在或发生在CLR外面的异常的基类

ComException

包含COM 类的HRESULT信息的异常

SEHException

封装win32 结构异常处理信息的异常

 

然而,在catch语句的内部,你已经有了随意处置的异常,就不必创建一个新异常。可能在表7.1 中的异常没有一个符合你特殊的要求——为什么不创建一个新的异常?在即将要学到小节中,都涉及到这两个话题。

 

7.3.1 重新引发异常

    当处于一个catch 语句的内部时,你可能决定引发一个目前正在再度处理的异常,进一步的处理留给一些外部的try-catch 语句。该方法的例子如 清单7.8所示。

 

清单 7.8  重新引发一个异常

 

 1:   try

 2:   {

 3:    checked

 4:    {

 5:     for (;nCurDig <= nComputeTo; nCurDig++)

 6:      nFactorial *= nCurDig;

 7:    }

 8:   }

 9:   catch (OverflowException oe)

10:   {

11:    Console.WriteLine("Computing {0} caused an overflow exception", nComputeTo);

12:    throw;

13:   }

 

注意,我不必规定所声明的异常变量。尽管它是可选的,但你也可以这样写:

throw oe;

现在我们还必须留意这个异常。

 

7.3.2  创建自己的异常类

尽管建议使用预定义的异常类,但在实际场合,创建自己的异常类可能会很方便。创建自己的异常类,允许你的异常类的使用者根据该异常类采取不同的手段。

在清单 7.9 中出现的异常类 MyImportantException遵循两个规则:第一,它用Exception结束类名。第二,它实现了所有三个被推荐的通用结构。你也应该遵守这些规则。

清单  7.9   实现自己的异常类  MyImportantException

 

 1: using System;

 2:

 3: public class MyImportantException:Exception

 4: {

 5:  public MyImportantException()

 6:   :base() {}

 7:

 8:  public MyImportantException(string message)

 9:   :base(message) {}

10:

11:  public MyImportantException(string message, Exception inner)

12:   :base(message,inner) {}

13: }

14:

15: public class ExceptionTestApp

16: {

17:  public static void TestThrow()

18:  {

19:   throw new MyImportantException("something bad has happened.");

20:  }

21:

22:  public static void Main()

23:  {

24:   try

25:   {

26:    ExceptionTestApp.TestThrow();

27:   }

28:   catch (Exception e)

29:   {

30:    Console.WriteLine(e);

31:   }

32:  }

33: }

 

正如你所看到的,MyImportantException 异常类不能实现任何特殊的功能,但它完全基于System.Exception类。使用一条catch 语句于System.Exception 类,程序的剩余部分测试新的异常类。

如果没有特殊的实现而只是给MyImportantException定义了三个构造函数,创建它又有什么意义呢?它是一个重要的类型——你可以在catch语句中使用它,代替更为普通的异常类。可能引发你的新异常的客户代码可以按规定的catch代码起作用。

当使用自己的名字空间编写一个类库时,也要把异常放到该名字空间中。尽管它并没有出现在这个例子中,你还是应该使用适当的属性,为扩展了的错误信息扩充你的异常类。

 

7.4  异常处理的“要”和“不要”

  作为最后的忠告之语,这里是对异常引发和处理所要做和不要做的清单:

。要提供有意义的文本,当引发异常时。

。要引发异常,仅当条件是真正异常,也就是当一个正常的返回值不满足时。

。要引发一个ArgumentException异常, 如果你的方法或属性被传递一个坏参数时。

。要引发一个 InvalidOperationException异常,当调用操作不适合对象的当前状态时。

。要引发最适合的异常。

。要使用链表异常,它们允许你跟踪异常树。

。不要为正常或预期的错误使用异常。

。不要为流程的正常控制使用异常。

。不要在方法中引发 NullReferenceExceptionIndexOutOfRangeException异常。

 

   7.5  小结

这一章由介绍溢出检查开始。你可以使用编译器开关(默认是关),使整个应用程序允许或禁止溢出检查。如果需要微调控制,你可以使用检查和非检查语句,它允许你用或不用溢出检查来执行一段代码,尽管没有设置应用程序开关。

当发生溢出时,一个异常就被引发了。如何处理异常取决于你。我提到了各种途径,包括你最有可能贯穿整个应用程序中使用的:trycatch finally 语句。在伴随的多个例子中,你学到了它与WIN32结构异常处理(SEH)的差别。

    异常处理供类的用户使用; 然而,如果你负责创建新的类,就可以引发异常。有多种选择:引发早已捕获的异常,引发存在的框架异常,或者按规定的实际目标创建新的异常类。

最后,你需要阅读引发和处理异常的每一条“要”和“不要”。

 

 

 

0 0

相关博文

我的热门文章

img
取 消
img