20230704172025.NET开发中的异常处理

开发中的异常处理.NET异常引发准则:不要返回错误代码异常是报告框架中的错误的主要手段通过引发异常来报告执行故障如果某一成员无法按预期方式成功执行，则应将这种情况视为一个执行故障并引发一个异常如果代码遇到继续执行则不安全的情况，应考虑通过调用System.Environment.FailFastSystem.String.NET中的一种功能来终止进程，而不是引发异常Framework

2.0尽可能不对正常控制流使用异常除了系统故障及可能导致争用状态的操作之外，框架设计人员还应设计一些以便用户可以编写不引发异常的API代码例如，可以提供一种在调用成员之前检查前提条件的方法，以便用户可以编写不引发异常的代码考虑引发异常的性能影响记录公共可调用的成员因成员协定冲突而不是系统故障而引发的所有异常，并将这些异常视为协定的一部分包含在协定中的异常不应从一个版本更改到下一个版本不要包含可以根据某一选项引发或不引发异常的公共成员例如，不要定义如下所示的成员Uri ParseUristringuriValue,bool throwOnError不要包含将异常作为返回值或输出参数返回的公共成员考虑使用异常生成器方法从不同的位置引发同一异常会经常发生为了避免代码膨胀，请使用帮助器方法创建异常并初始化其属性不要从异常筛选器块中引发异常当异常筛选器引发异常时，公此行为false与筛选器显式执行和返的行为无法区分，因此很难调试false共语言运行库将捕获该异常，然后该筛选器返CLR避免从块中显式引发异常可以接受因调用引发异常的方法而finally隐式引发的异常异常处理准则:不要在框架代码中捕捉非特定异常如、System.Exception等以至忽略错误System.SystemException下面的代码示例演示的异常处理是不正确的public classBadExceptionHandlingExamplelpublic voidDoWork//Do somework thatmight throw exceptions.}public voidMethodWithBadHandlertryDoWork;}catch Exceptione//Swallow the exception and continue//executing.}}}避免在应用程序代码中捕捉非特定异常如System.Exception,等以至忽略错误某些情况下，可以在应用System.SystemException程序中忽略错误，但这种情况极少如果捕捉异常是为了传输异常，则不要排除任何特殊异常面的代码示例演示对以再次引发为的特殊异常进行的不正确F测试public classBadExceptionHandlingExample2public voidDoWorkQ〃Do somework thatmight throw exceptions.}public voidMethodWithBadHandlerQ tryDoWork;}catch Exceptioneif eis StackOverflowException||e isOutOfMemoryExceptionthrow;//Handle exceptionandcontinue//executing.}}如果了解特定异常在给定上下文中引发的条件，请考虑捕捉这些异常不要过多使用通常应允许异常在调用堆栈中往上传播catch使用并避免将用于清理代码在书写规范try-finally try-catch，的异常代码中比使用得更多try-finally try-catch捕捉并再次引发异常时，首选使用空引发这是保留异常调用堆栈的最佳方式下面的代码示例演示一个可引发异常的方法public voidDoWorkObject anObject〃Do somework thatmight throwexceptions.if anObject==nullthrow newArgumentNullExceptionCanObject,Specify anon-null argument.;}//Do workwith o.}下面的代码示例演示捕捉一个异常，并在再次引发该异常时对它进行错误的指定这会使堆栈跟踪指向再次引发作为错误位置，而不是指向方法DoWorkpublic voidMethodWithBadCatchObject anObjecttryDoWorkanObject;}catch ArgumentNullExceptioneSystem.Diagnostics.Debug.Writee.Message;//This iswrong.throwe;//Should bethis://throw;}}不要使用无参数块来处理不符合的异常不是从catch CLS派生的异常支持不是从派生的异常的System.Exception Exception语言可以处理这些不符合的异常CLS捕捉和引发标准异常类型:和Exception SystemException不要弓发或I System.Exception System.SystemException不要在框架代码中捕捉或System.Exception除非打算再次引发System.SystemException,避免捕捉或在顶System.Exception System.SystemException,级异常处理程序中除外ApplicationException不要引发或从该异常进行派生System.ApplicationExceptionInvalidOperationException如果处于不适当的状态，则引发异常如果没有向属性集或方法System.InvalidOperationException调用提供适当的对象当前状态，则应引发System.InvalidOperationExceptiono例如，向已打开用于读取的写入时，应弓发I异常System.InvalidOperationException、和ArgumentException ArgumentNullExceptionArgumentOutOfRangeException如果向成员传递了错误的参数，则引发或其子类型之一如果适用，首选派生程System.ArgumentException度最高的异常类型在引发或其派生类型之一时，设置System.ArgumentException属性此属性存储导致引System.ArgumentException.ParamName发异常的参数的名称注意，使用其中一个构造函数重载可以设置该属性使用属性的隐式值参数的名称的值setter不要允许公开可调用的显式或隐式引发APISystem.NullReferenceException■System.AccessViolationException.或System.InvalidCastException进行参数检直以避免引发这些System.IndexOutOfRangeException异常引发这些异常会公开方法的实现细节，这些细节可能会随时间发生更改°StackOverflowException不要显式引发此异常只应由公System.StackOverflowExceptiono共语言运行库显式引发CLR不要捕捉System.StackOverflowExceptiono以编程方式处理堆栈溢出极为困难应允许此异常终止进程并使用调试确定问题的根源OutOfMemoryException不要显式引发此异常只应System.OutOf MemoryException由基础结构引发CLR和ComException SEHException不要显式引发或System.Runtime.InteropServices.COMException这些异常只应由基础结构引发CLRo显式捕捉oExecutionEngineException不要显式引发System.ExecutionEngineExceptiono设计自定义异常:一定要从或其他常见基本异常之一派生异常System.Exception避免使用深的异常层次结构请注意，捕捉和引发标准异常类型中有一条规定，不应从派生自定义异常ApplicationException异常类名称一定要以后缀结尾Exception应使异常可序列化异常必须可序列化才能跨越应用程序域和远程处理边界正确工作一定要在所有异常上都提供（至少是这样）下列常见构造函数请确保参数的名称和类型与使用者相同.代码如下:public classNewException:BaseException,ISerializablepublic NewExceptionO//Add implementation.}public NewExceptionstring message//Add implementation.}public NewExceptionstringmessage.Exception inner//Add implementation.}//This constructoris neededfor serialization.protected NewExceptionSerializationInfoinfo.Streamingcontext context〃Add implementation.}}一定要只在要求适合的权限后，才通过的重写报告安全敏感信息如果权限要求失败，则返回一个不包括安全敏感信息的字符串一定要以私有异常状态存储有用的安全敏感信息请确保只有受信任的代码才能获取该信息考虑提供异常属性，以便可以以编程方式访问除消息字符串之外与异常相关的额外信息异常和性能不要由于担心异常可能会对性能造成不良影响而使用错误代码对于可能在常见方案中引发异常的成员，可以考虑使用Tester-Doer模式来避免与异常相关的性能问题的代码如下Doerpublic classDoer{//Method thatcan potentialthrowexceptionsoften,public staticvoid ProcessMessagestringmessageif message==nullthrow newArgumentNullExceptionCmessage;}}//Other methods...}代码如下Testerpublic classTesterpublic staticvoid TesterDoerICollectionstring messagesforeachstringmessagein messages〃Test toensure thatthe call//wont causetheexception.if message!=nullDoer.ProcessMessagemessage;}}}}对于可能在常见方案中引发异常的成员，可以考虑使用模式TryParse来避免与异常相关的性能问题代码如下int i=0;intj=0;bool IsPrel=Int

32.TryParse30out i;fbool IsPre2=Int

32.TryParse12s outj;f〃执行之后i=30,j=0;IsPrel=true,IsPre2=false;为每个使用模式的成员提供一个引发异常的成员TryParse。