Exception-异常处理(c++)的总结

Exception-异常处理(c++)的总结
Exception（异常处理机制），早期的C语言的异常处理机制，通常是人为的对返回结果加一些标志来进行判定。C语言的异常处理机制全是人为的定义，这样就会造成业务逻辑的主线受到异常处理的牵制，或者说是难免会将注意力转移，并且造成业务逻辑与异常处理之间有很大程度上的缠绕。

为什么要自定义自己的Exception ，Java Exception机制与传统的C语言的异常处理机制有什么不同，这种Exception机制的意义在什么地方？接下来咱就来和你一起探讨Exception 的优缺点。

早期的C语言的异常处理机制，通常是我们人为的对返回结果加一些标志来进行判定，比如发生错误返回什么标志，正常情况下我们又是返回什么标记，而这些都不是语言本身所赋予我们的，而对于C语言这种机制又有什么问题哩？为什么新一代的语言 Java Ruby C# 等都用Exception机制而不是维持C语言的老样子？这些都是我们需要思考的问题。

中止模型

假设错误非常严重，已至你无法在回到错误发生的地方，也就是说，这段程序经过判断认为，他已经没有办法挽回，于是就抛出异常，希望这个异常不要在回来，这也是Java 当前所采用的模式。

继续模型

这种模型的主旨是恢复当前的运行环境，然后希望能够重新回到错误的发生地，并希望第二次的尝试能够获得成功，这种模型通常为操作系统所应用。

此类是所有异常的基类。当发生错误时，系统或当前正在执行的应用程序通过引发包含关于该错误的信息的异常来报告错误。异常发生后，将由该应用程序或默认异常处理程序进行处理。

公共语言运行库提供一种异常处理模型，该模型基于对象形式的异常表示形式，并且将程序代码和异常处理代码分到 try 块和 catch 块中。可以有一个或多个 catch 块，每个块都设计为处理一种特定类型的异常，或者将一个块设计为捕捉比其他块更具体的异常。

如果应用程序将处理在执行应用程序代码块期间发生的异常，则代码必须放置在 try 语句中。try 语句中的应用程序代码是 try 块。处理由 try 块引发的异常的应用程序代码放在 catch 语句中，称为 catch 块。零个或多个 catch 块与一个 try 块相关联，每个 catch 块均包含一个确定该块处理的异常类型的类型筛选器。

在 try 块中出现异常时，系统按所关联 catch 块在应用程序代码中出现的顺序搜索它们，直到定位到处理该异常的 catch 块为止。如果某 Catch 块的类型筛选器指定 T 或任何派生出 T 的类型，则该 catch 块处理 T 类型的异常。系统在找到第一个处理该异常的 catch 块后即停止搜索。因此，正如本节后面的示例所演示的那样，在应用程序代码中处理某类型的 catch 块必须在处理其基类型的 catch 块之前指定。处理 System.Exception
的 Catch 块最后指定。

如果当前 try 块所关联的所有 catch 块均不处理该异常，且当前 try 块嵌套在当前调用的其他 try 块中，则搜索与下一个封闭 try 块相关联的 catch 块。如果没有找到用于该异常的 catch 块，则系统搜索当前调用中前面的嵌套级别。如果在当前调用中没有找到用于该异常的 catch 块，则将该异常沿调用堆栈向上传递，搜索上一个堆栈帧来查找处理该异常的 catch 块。继续搜索调用堆栈，直到该异常得到处理或调用堆栈中没有更多的帧为止。如果到达调用堆栈顶部却没有找到处理该异常的
catch 块，则由默认的异常处理程序处理该异常，然后应用程序终止。

异常类型支持下面的功能：

描述错误的可读文本。当异常发生时，运行库产生文本消息通知用户错误的性质并提供解决该问题的操作建议。此文本消息保存在异常对象的 Message 属性中。在创建异常对象过程中，可以将文本字符串传递给构造函数以描述该特定异常的详细信息。如果没有向构造函数提供错误信息参数，则将使用默认错误信息。

发生异常时调用堆栈的状态。StackTrace 属性包含可以用来确定代码中错误发生位置的堆栈跟踪。堆栈跟踪列出所有调用的方法和源文件中这些调用所在的行号。

基类 Exception 下存在两类异常：

从 SystemException 派生的预定义公共语言运行库异常类。

从 ApplicationException 派生的用户定义的应用程序异常类。

Exception 包含很多属性，可以帮助标识异常的代码位置、类型、帮助文件和原因：StackTrace、InnerException、Message、HelpLink、HResult、Source、TargetSite 和 Data。

当在两个或多个异常之间存在因果关系时，InnerException 属性会维护此信息。作为对此内部异常的反应将引发外部异常。处理外部异常的代码可利用以前的内部异常的信息更妥当地处理错误。关于异常的补充信息可以存储在 Data 属性中。

应本地化在创建异常对象过程中传递给构造函数的错误信息字符串，这种字符串可以使用 ResourceManager 从资源文件提供。有关本地化资源的更多信息，请参见“System.Resources 命名空间概述”和“打包和部署资源”。

若要向用户提供有关异常发生原因的大量信息，可以使用 HelpLink 属性保存帮助文件的 URL（或 URN）。

Exception 使用具有值 0x80131500 的 HRESULT COR_E_EXCEPTION。

有关 Exception 实例的初始属性值列表，请参见 Exception 构造函数。

性能注意事项

引发或处理异常时，将使用大量的系统资源和执行时间。引发异常只是为了处理确实异常的情况，而不是为了处理可预知的事件或流控制。例如，如果方法参数无效，而应用程序需要使用有效的参数调用方法，则可以引发异常。无效的方法参数意味着出现了异常情况。相反，用户偶尔会输入无效数据，这是可以预见的，因此如果用户输入无效，则不要引发异常。在这种情况下，请提供重试机制以便用户输入有效输入。

仅对特别条件引发异常，然后在应用于大多数应用程序的常规异常处理程序中捕捉异常，而不是在应用于特定异常的处理程序中捕捉异常。此方法的基础在于，大多数错误都可以通过验证以及与错误接近的错误处理代码进行处理；不需要引发和捕捉异常。通用目的异常处理程序捕捉的是在应用程序任意位置引发的、真正不可预期的异常。

此外，返回代码正常时不要引发异常；不要将返回代码转换为异常；也不要例行公事地捕捉异常、忽略异常，然后继续处理。

using namespace System;

int main()

{

int x = 0;

try

{

int y = 100 / x;

}

catch ( ArithmeticException^ e )

{

Console::WriteLine( "ArithmeticException Handler: {0}", e );

}

catch ( Exception^ e )

{

Console::WriteLine( "Generic Exception Handler: {0}", e );

}

}

(完)