.NET设计规范(六) 异常

第6章       异常

    设计异常的唯一目的是报告错误。

6.1.   抛出异常

   û 不要返回错误码。

 

   ü 要通过抛出异常的方式来报告操作失败。

 

   ü 考虑通过调用System.Environment.FailFast来终止进程，而不是抛出异常，如果代码遇到了严重问题，已经无法继续安全的执行。

 

   û 如果能够避免的话，不要在正常的控制流中使用异常，。

    double a = 98, b = 0;

    double result = 0;

    try

    {

        result = SafeDivision(a, b);

        Console.WriteLine("{0} divided by {1} = {2}", a, b, result);

    }

    catch (DivideByZeroException e)

    {

       //bad

        result = SafeDivision(a, 2);

        Console.WriteLine("Attempted divide by zero.");

    }

    Console.ReadKey();

 

   ü 考虑抛出异常可能会对性能造成的影响。

 

   ü 要为所有的异常撰写文档，并把它们作为协定的一部分，前提是这些异常是由于违反了公有成员的协定而抛出的。

 

   û 不要让公有成员根据某个选项来决定是否抛出异常。

    static double SafeDivision(double x, double y,bool throwOnError)

    {

        //bad

        if (y ==0)

        {

            if (throwOnError)

                throw new System.DivideByZeroException("Attempted divide by                   zero.");

        }

        return x / y;

    }

 

   û 不要把异常用作公有成员的返回值或输出参数。

    //bad

    public Exception DoSomething() { }

   

   ü 考虑使用辅助方法来创建异常。

     static double SafeDivision(double x, double y)

    {

        if (y == 0)

            ThrowNewDivideByZeroException();

        return x / y;

    }

    static void ThrowNewDivideByZeroException()

    {

        string description = "Attempted divide by zero.";

        throw new System.DivideByZeroException(description);

    }

 

   û 避免显示的从finally代码块中抛出异常。

     finally

    {

        if (y == 0)

            throw new System.DivideByZeroException();

        Console.ReadLine();

    }

6.2.   为抛出的异常选择合适的类型

   ü 考虑优先使用System名字空间中已有的异常，而不是自己创建新的异常类型。

 

    ü 如果对错误的处理方式或其他已有的异常有所不同，要使用自定义的异常类型。否则的话，应该使用已有的异常。

 

       û 不要仅仅为了拥有自己的异常而创建并使用新的异常，要使用最合理，最有针对的异常。

    try

    {

        object ObjPerson = null;

        if (ObjPerson == null)

            throw new ArgumentNullException();//good

            throw new ArgumentException();//bad

        Console.WriteLine(ObjPerson.ToString());

    }

    catch (ArgumentNullException e)

    {

        ……….

    }

 

6.2.1.    错误消息的设计

   ü 要在抛出异常时为开发人员提供丰富而有意义的错误消息。

 

   ü 要确保异常消息的语法正确无误。

 

   ü 要确保异常消息中的每个句子都有句话。

 

   û 避免在异常消息中使用问号和惊叹号。

 

   û 不要在没有得到许可的情况下在异常消息中泄漏安全消息。

 

   ü 考虑把组件抛出的异常消息本地化，如果希望组件为不同语言的开发人员所使用。

     try

    {

          if (y == 0)

          throw new System.DivideByZeroException("Attempted divide by               zero.");

    }

6.2.2.    异常处理

   û 不要在框架的代码中，在捕获具体类型不确定的异常时，把错误吞了。

 

   û 不要在转移异常而编写的catch代码块中把任何特殊的异常排除在外。

 

   ü 考虑捕获特定类型的异常，如果理解该异常在具体环境中产生的原因，并能对错误做出适当的反应。

 

   û 不要捕获不应该捕获的异常。通常应该允许异常沿着调用栈向上传递。

 

   ü 要在进行清理工作时使用try-finally，避免使用try-catch，catch代码块是来从错误中恢复。Finally代码是来清理的。

          

   ü 要在捕获并重新抛出异常是使用空的throw语句。

     try

    {

        stream = new FileStream(......);

    }

    finally

    {

        if(stream != null) stream.Close();

}

 

   û 不要用无参数的catch块来处理不符号CLS规范的异常。

6.2.3.    对异常进行封装

   ü 考虑对较低层次抛出的异常进行适当的封装。

 

   û 避免捕获并封装具体类型不确定的异常。

 

   ü 要在对异常进行封装时为其指定内部异常。

6.3.   标准异常类型的使用

6.3.1.    Exception与SystemException

    û 不要抛出System.Excepton或System.SystemException异常。

 

    û 不要在框架代码中捕获System.Excepton或System.SystemException异常，除非打算重新抛出。

 

    û 避免捕获System.Exception或System.SystemExcepton异常，除非是在顶层的异常处理器中。

    catch(Exception e)

    {

        Console.Write(……);

        throw;

    }

6.3.2.    ApplicationException

    û 不要抛出System.ApplicationException或从它派生新类。

6.3.3.    InvalidOperationException

    ü 要抛出InvalidOperationException异常，如果对象处于不正确的状态。

6.3.4.    ArgumentException、ArgumentNullException及ArgumentOutOfRangeException

    ü 要抛出ArgumentException异常或其子类，如果传入的是无效参数。

 

    ü 要在抛出ArgumentException异常或其子类时设置ParamName属性。

 

    ü 要在属性的设置方法中，以value作为隐式值参数的名字。

     public string Name

     {

        set

        {

            if(value == null){

            throw new ArgumentNullException("value", …);

            }

        }

     }

6.3.5.    NullReferenceException、IndexOutOfRangeException及AccessViolationException

    û 不要让公用API显示的或隐式的抛出NullReferenceException、AccessViolatonException或IndexOutOfRangeException异常。

6.3.6.    StackOverFlowExcetion

    û 不要显示的抛出StackOverflowException异常。应该只有CLR才能显式的抛出该异常。

 

    û 不要捕获StackOverflowException异常。

6.3.7.    OutOfMemoryException

    û 不要显示的抛出OutOfMemoryException异常。应该只有CLR才能抛出该异常。

6.3.8.    ComException、SEHException及其他CLR异常

    û 不要显示的抛出InteropException,ComException及SEHException异常。应该只有CLR才能抛出这些异常。

 

   û 不要显示的捕获SEHExcepton异常。

6.3.9.    ExecutionEngineException

    û 不要显示的抛出ExecutionEngineException异常。

6.4.   自定义异常的设计

    û 避免太深的继承层次。

 

    ü 要从System.Exception或其它常用的异常基类派生新的异常类。

 

    ü 要在命名异常类时使用Exception后缀。

 

    ü 要使异常可序列化。为了使异常能够跨应用程序域。

 

    ü 要为所有的异常提供下面常用的构造函数。

    public class SomeException:Exception,ISerializable

    {

        Public SomeException();

        Public SomeException(string message);

        Public SomeException(string message,Exception inner);

        Protected SomeException(SerializationInfo info,StreamingContext context);

    }

    ü 要把与安全性有关的信息保存在私有的异常状态中。

 

    ü 考虑为异常定义属性。

6.5.   异常与性能

    û 不要因异常可能对性能造成的负面影响而使用错误码。

6.5.1.    Tester–Doer模式

    ü 考虑在方法中使用Tester-Doer模式来避免因异常而引起的性能问题。

    ICollection<int> numbers= ...

if(!numbers.IsReadOnly)

{

       numbers.Add(1);

}

用来对条件进行测试的成员称为tester，在前面的例子中就是IsReadOnly。用来执行实际的操作并可能会抛出异常的成员称为doer.在上例中就是Add方法。

 

6.5.2.    Try-Parse模式

    ü 考虑在方法中使用Try-Parse模式来避免因异常而引起的性能问题。

 

    ü 要在实现Try-Parse模式时使用Try前缀，并用布尔类型作为方法的返回类型。

 

    ü 要为每个使用Try-Parse模式的方法提供一个会抛出异常的对应成员。

    public struct DateTime

    {

       public static DateTime Parse(string dateTime){……}

       public static bool TryParse(string dateTime,out DateTime result){…..}

 }