.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){…..} } (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |