CN105103134A - 通过最小化差错恢复逻辑来改善软件系统 - Google Patents

Abstract

处理程序执行中的错误。该方法包括标识包括多个显式地标识出的失败状况的集合。该方法进一步包括确定已发生了这些显式标识出的失败状况中的一个或多个。结果，该方法进一步包括停止预定的第一计算执行范围，并向另一计算范围通知该失败状况。一替换实施例可在计算环境中实施，并包括处理错误的方法。该方法包括标识包括多个显式地标识出的失败状况的集合。该方法进一步包括确定已发生了不在该包括多个显式地标识出的失败状况的集合中的错误状况。作为结果，该方法进一步包括停止预定的第一计算执行范围，并向另一计算范围通知该失败状况。

Description

通过最小化差错恢复逻辑来改善软件系统

背景

计算机和计算系统已经影响了现代生活的几乎每个方面。计算机通常涉及工作、休闲、保健、运输、娱乐、家政管理等。计算机功能通常是计算系统执行软件代码的结果。

非常大部分的现代软件代码旨在发现错误状况、报告错误状况和从错误状况中恢复。在现实世界场景中，错误状况相对罕见并且通常难以模拟，然而程序员投入了大量的资源来处理它们。

在软件系统内，差错恢复代码中存在与这些系统中的全部代码相比不成比例的隐错数。这与以下事实有关：错误状况通常难以模拟，结果通常保持未被测试，直到消费者遇到了该领域的底层问题。不合适的错误恢复逻辑可导致复合错误，并最终导致崩溃和数据破坏。

常规的软件系统混合有不同类型的错误状况，并提供单个机制来处理这些错误状况。这种一致性表面上很吸引人，因为它允许开发者以单个一致的方式为系统推理出错误状况。不幸地是，这种一致性使错误的定性差异模糊。

在此要求保护的主题不限于解决任何缺点或仅在诸如上述环境中操作的各个实施例。相反，提供该背景仅用以示出在其中可实践在此描述的部分实施例的一个示例性技术领域。

概述

一个实施例可以是具有用于处理错误的动作的在计算环境中实施的方法。该方法包括标识包括多个显式地标识出的失败状况(failurecondition)的集合。该方法进一步包括确定已发生了这些显式地标识出的失败状况中的一个或多个。结果，该方法进一步包括停止预定的第一计算执行范围，并向另一计算范围通知该失败状况。

一替换实施例可在计算环境中实施，并包括用于处理错误的方法。该方法包括标识包括多个显式地标识出的失败状况的集合。该方法进一步包括确定已发生了不在该包括多个显式地标识出的失败状况的集合中的错误状况。作为结果，该方法进一步包括停止预定的第一计算执行范围，并向另一计算范围通知该错误状况。

提供本概述是为了以精简的形式介绍将在以下详细描述中进一步描述的一些概念。本概述并不旨在标识出所要求保护的主题的关键特征或必要特征，也不旨在用于帮助确定所要求保护的主题的范围。

将在以下的描述中阐述另外的特征和优点，并且部分特征和优点可从该描述中显而易见，或者可从本文教导的实践中获知。本发明的特征和优点可以通过在所附权利要求中特别指出的手段和组合来实现并获取。本发明的特征将从以下描述和所附权利要求书中变得完全显而易见，或者可通过如下所述对本发明的实践而获知。

附图简述

为了描述可获得本主题的上述和其它优点和特征的方式，将通过参考附图中示出的本主题的具体实施例来呈现以上简要描述的本主题的更具体描述。应该理解，这些附图仅描绘了各典型实施例，因此其不应被认为是对范围的限制，各实施例将通过使用附图用附加特征和详情来描述并解释，在附图中：

图1示出了一计算执行范围；

图2示出了代码主体和用编译器编译该代码；

图3示出了受管代码系统；

图4示出了处理错误的方法；以及

图5示出了处理错误的另一个方法。

详细描述

各实施例将全部失败状况显式地划分成“预期”失败状况和“非预期”失败状况。软件被预期从预期失败就地恢复，而非预期失败被在外部处理。这样做是因为依据定义这些失败是非预期的，并且软件没有为这些失败做好准备。各实施例可包括多个不同的机制中的一者或多者，以使得软件环境有可能系统地标识出哪些失败是预期的及哪些失败不是预期的，使得可发生正确的处置。参考图1，各实施例可将软件执行范围100内发生的错误状况的整个集合102划分成两种类型，并提供用于处理每一种类型的专用机制。在这样做时，各实施例得到范围从改善的正确性到改善的性能的多个益处。参考图1，识别出的两种宽泛类型的错误状况的实施例为可内部地恢复的状况104和可外部地恢复的状况106。

可内部地恢复的状况104是软件执行范围100能够可靠地发现并从本地计算范围内恢复的错误状况。这些错误源自以下两个宽泛的源：I/O失败和语义失败。

可外部地恢复的状况106是各实施例确定软件装备不良无法就地处理并因此由外部代理108来处理的状况。可外部地恢复的错误状况一般源自以下两个宽泛的源：软件缺陷(即，隐错)和元失败(例如，无法分派存储器)。元失败是与计算的语义不直接相关并作为该计算在其中执行的虚拟环境中的约束的结果的失败。例如，计算预期具有它可将局部变量推送到其上的栈。如果虚拟环境向栈的深度施加了限制，则计算一般无法预测该限制将何时发生，并且可能在到达这样的限制时没有恢复路径。类似地，计算通常预期能够分派存储器，并且无法获得新的存储器是元失败。

在这样的错误发生时，其中发生了该错误的计算范围100已在某种程度上受损，并因此无法注意到该错误状况并从其恢复。由此，将错误处理留给在未受损范围110中操作的外部代理108。例如，在无法分派存储器的情况下，请求无法分派存储器的原始计算范围100中的代理开始恢复算法通常可导致该代理尝试分派存储器来执行该恢复算法。这没有多大意义。相反，能够分派存储器或者已经分派了用于恢复的存储器的外部代理108可能够更好地处理该错误。

对“用完存储器”的常见响应事实上是完全放弃该操作。尽管在常规的系统中经历用完存储器状况的代码必定包含非常大量的错误检查和昂贵的用于在失败情况下进行清理的取消逻辑，在本文中的实施例各中，代码可被编写就好像分派将一直成功一样。如果分派确实失败了，则各实施例立即停止运行任意更多代码，并服从于另一上下文，该另一上下文可随后将整个操作看作已经失败。

在常规系统中，存在提供对错误状况进行根本不健全的本地运行时检测、报告和恢复的非常大量的代码。该代码可能会偶尔成功，但它通常是无用的练习。本文中公开的一些实施例系统地放弃该代码，从而导致没有容易出错的取消逻辑的负担的短的多的源代码。

各实施例组合多个技术来将错误状况系统地划分成以上两种类型，并使得编程器能够显式地推理出哪些代码可能失败以及哪些代码不可能失败。通过系统地应用这些技术，各实施例实现了相当多的正确性、性能和开发时间益处。

以下示出了本文中公开的各个实施例中的一个或多个的各方面中的几个方面的简要概述。如上所述的各实施例可实现错误类型划分。各实施例可系统地将所有错误状况分成可内部地恢复的错误104和可外部地恢复的错误106，并向每一者显式地应用不同的处置策略。

各实施例可实现在本文中被称为放弃的概念。放弃是立即挂起被破坏的范围(诸如例如软件执行范围100)内的计算的执行的机制。操作系统进程用作典型的放弃上下文范围，但如以下更详细示出的，其他进程是可能的。当放弃发生时，没有在该计算的范围内的附加代码执行，从而防止引入进一步的破坏，并改为允许外部代理来尝试进行恢复。

各实施例可实现具有放弃的整体合约。系统可定义基于合约的设计方法。本文中公开的一些实施例在操作系统中引入对合约的使用，从而除了使用操作系统实现内的合约外，还利用用于定义所有操作系统接口的合约。合约定义了逻辑代理要求的静态不变式要求集合。例如，合约可定义到逻辑代理的可接受的输入。如果这些静态不变式要求中的任一没有被满足，则该合约被违反。各实施例通过将合约违反看作合约所适用的违反者或逻辑代理无法校正的情况来扩展经典的合约模型，这使得这样的违反进入到可外部地恢复的错误106中。

各实施例可实现具有放弃的受管运行时。尽管常规的受管语言系统(诸如Java和C#)依赖于异常来报告运行时级别的错误(诸如，界外阵列访问、空解除引用或用完存储器的状况)，但各实施例将所有这样的事件都看作对运行时的合约先决条件的违反，从而导致放弃。

各实施例实现具有放弃的存储器耗尽。尽管常规系统尝试向编程器系统地报告所有形式的存储器耗尽，但本文中公开的一些实施例将这样的事件看作不可内部地恢复，并因此它们仅是导致当前计算的放弃的可外部地恢复的错误106。

各实施例可为可内部地恢复的错误状况实现异常效果系统。通过使用以上机制，各实施例可显著地减少需要针对可内部地恢复的错误状况的恢复逻辑的软件量。这使得有可能引入效果系统来使得编程器和编译器清楚哪些方法和代码块可经历可恢复的错误(如图2中不能失败的代码202所示的)以及哪些方法和代码块不能经历可恢复的错误(如图2所示的能失败的代码204所示的)。在一些实施例中，各方法和代码块可注释有指示它是否可内部地恢复的元数据。这使得系统和应用代码内的大型调用图能够在假定没有内部错误的情况下被写出。这使得受影响的代码写和推理起来容易的多，并且改善了用于发现软件中可导致可外部地恢复的错误状况106的缺陷的静态分析能力。以下示出了代码注释示例。该示例示出了各方法可被声明为抛出异常。在没有被注释时，一方法不能抛出异常并因此没有经历到或引入任何可内部地恢复的错误。结果，对这一方法的调用被看作不易出错，并且不需要错误恢复逻辑。然而，M2被注释为抛出，并因此对这一方法的调用必定在“try(尝试)”关键词之前以向编程器指示潜在的失败点。此外，由于该调用可失败，错误恢复逻辑是必须的，该错误恢复逻辑被包含在catch(捕捉)子句中。

//不产生可恢复的错误的方法

voidMl0

{

}

//可产生可恢复的错误的方法

throwsvoidM2()

{

}

{

//该调用不能失败

Ml()；

try{

//该调用可失败，如“try”关键词所说明的

tryM2()；

}

Catch{

//为M2的失败实现恢复逻辑

}

}

各实施例可体验经改善的性能。编译器通过利用放弃和异常效果系统的特定语义来得到优化机会。此外，在热路径中存在更少开发者写的代码，这趋于改善微处理器指令高速缓存的有效性。

以下示出了附加的细节。

可内部地恢复的错误状况104和可外部地恢复的错误状况106之间的区别限定了如何构建本文中公开的一些实施例。各实施例在系统的不同级别处识别该对偶性，并在分解系统功能时将它用作向导原理。

可内部地恢复的错误状况104一般源自两个宽泛的源。一个源是来自I/O失败。计算机系统执行到外部设备(诸如硬盘114或网络适配器116)的I/O操作112，并且这样的操作112本质上易于出错。盘驱动器114可失败，网络电缆可断开连接等。I/O操作112通常在软件系统中以相当粗略的级别执行，从而使其适合于错误恢复逻辑。

可内部地恢复的错误的第二个源是语义失败。当新数据118已输入系统时，这些语义失败在I/O操作112后发生。传入数据118的形状和大小通常服从各种约束120，并且在这些约束120被违反时，发生了语义失败。与I/O失败相同，语义失败是消耗任何数据的预期部分，并且软件一般装备良好以发现这些语义失败、报告这些语义失败并从这些语义失败中恢复。

为了可靠地从I/O失败或语义失败中恢复，在一些实施例中，该软件假定不存在元失败和软件缺陷。当软件不根据预期来表现时，该软件被认为是有缺陷的。缺陷可通过软件的非预期终止(即，崩溃)或通过某种形式的错误输出而变得对软件的用户明显。软件本身可通过证实某些不变式必须成立并验证它们实际上在该软件的整个执行中都成立来发现缺陷。假设当恢复逻辑本身易遭受其无法控制的失败时，还可以写出稳健的恢复逻辑在逻辑上是不一致的。

可外部地恢复的错误状况106是由软件中的隐错或不受正经历该错误的计算或软件执行范围100的控制的环境问题造成的错误状况。该错误状况由外部代理108外部地处理，因为该错误将软件执行范围100保持在基本受损的状态，并因此在逻辑上无法通过自身来恢复。常规系统经常允许这样的受损的计算尝试从错误中恢复，这导致现代的大规模软件系统特有的元稳定性问题。

软件系统包括各种形式的对在该系统的生存期期间的任何时间点都被认为是真的条件(即，以上所述的不变式)的经验验证。当这样的验证失败时，它指示已检测到该软件中的隐错。由于计算无法用其自己的代码来从隐错中恢复，各实施例将这样的情况仅看作是可外部地恢复的状况106。

现参考图3，受管环境在虚拟机304顶部执行软件302。虚拟机304可经历与正被执行的计算306的语义完全无关的失败。各实施例调用这些元失败。例如，JIT编译器308可能在尝试动态地编译计算代码的一部分时已用完了存储器。这样的失败不服从内部恢复，因为编程器无法推理出虚拟机304的状态。任何恢复代码本身都可遭受相同的失败。

可内部地恢复的错误状况104可从大精度中获益。从语义上来说，编程器通常可准确地理解什么导致了该错误。相反，可外部地恢复的错误状况106在本质上是不精确的。当计算遇到可外部地恢复的错误状况106时，该计算(在执行范围100中运行)通过放弃来终止，并且不同的计算(例如，外部代理108)被通知并被预期来执行恢复任务。当它这么做时，该外部计算通常仅知晓到被放弃的计算的顶层输入，而不会对该错误的特定原因知情。

该精度损失实际上有助于减少错误处理逻辑的量并改善其质量。各实施例改为用粗略的外部逻辑来替换大量细粒度的内部错误发现、报告和恢复逻辑。这导致所写的源代码量的可观的减少，并在本质上使开发者推理起来容易的多。

根本上，由于由开发者来写代码，因此几乎无法推理出所有可能的失败和所有可能的恢复策略。常规的受管环境使得几乎每一条程序语句都易受到偶尔的失败的影响，而人类正好不会想到是在这些条款中。本文中公开的一些实施例显著地减少了需要写的恢复逻辑的量，并且改为要求将其写成在已知为可靠的上下文中执行。

对比错误类型

该表示出了各实施例可定义的两种错误类型之间的差别：

放弃表示特定执行范围100内的活动立即且不可逆的停止。执行范围100被定义为可从在该范围内部运行的计算到达的存储器位置的闭集合。执行范围可具有各种不同的粒度。例如，执行范围可以是进程，并且因此放弃导致进程终止。替换地，执行范围可以是进程群组，使得各实施例可放弃该进程群组。替换地，执行范围可以是一个或多个进程被实现在其上的机器，使得如果遇到不可恢复的错误则可将该系统作为整体放弃(导致重启)。在另一替换示例中，执行范围可存在于进程内，但不是该整个进程。在另一替换例中，执行范围可以是跨各常见执行范围的自定义范围。当已发生放弃时，计算被停止并且执行范围被环境回收利用。

如上所示，在一些实施例中，执行范围是一进程。然而，合适范围的确定可以是确定它是否被配备成从另一范围的失败中恢复。在给定尝试对某范围B的失败作出响应的某范围A的情况下，被A和B两者使用的资源被充分隔离使得B中的失败不将负面地干扰范围A的操作。如果情况是那样的，则各实施例可考虑该失败以适用于甚至更大的范围(例如，整个机器，而非仅一个进程)。

在一些实施例中，放弃中涉及的执行范围100表示从可外部地恢复的错误状况已发生的时间到该错误状况被识别出并且放弃被触发的时间点计算可能已产生突变的整个存储器位置集合。通过立即停止该计算，各实施例防止破坏进一步扩散。当计算被放弃时，其失败被报告给在不受第一范围的突变影响的正交范围110内的不同的计算(被示为外部代理108)。该不同的计算随后负责判定恢复过程。

一些实施例可在具有含放弃的整体合约架构的环境中实现。若干软件系统使用可从加利福尼亚州的戈利塔市的Eiffel软件中获得的Eiffel编程语言所倡导的基于合约的设计方法。本文中公开的一些实施例是围绕合约方法系统地设计的。在一些实施例中，实际上该系统的每一部分都用合约声明来指定并实现。例如，如图1所示，合约可用各约束120来具体化。以下示出了使用合约先决条件和后置条件来对软件系统中的约束进行编码。

//声明方法

intCompute(intx)

requiresx>0//对该方法的调用者的约束

ensuresreturn！＝0//对该方法的实现的约束

{

}

…

{

//调用该方法

inty＝Compute(-l)；//违反先决条件约束

intz＝Compue(l)；//满足先决条件约束

//由以上的“ensures”子句造成，在这时，z已知为！＝0

//(不等于零)

}

合约设计方法使得编程器能够指定对各个体软件抽象化可以保持的值和值组合的约束120。这些约束120补充类型系统已经施加的那些。例如，合约先决条件可指定给定方法参数应当在0到31的范围内，其是在正常整数参数可具有的所有可能值上的约束。

在典型系统中，合约违反导致某种形式的可内部地恢复的错误状况对计算可见。例如，在Eiffel中，合约违反会抛出异常。在本文中公开的一些实施例中，各实施例将合约违反看作表示软件中的隐错，而实际上为两个组件之间关于其相互责任的分歧。依其本质，软件隐错不可就地恢复，因为编程器可能需要涉及以某种方式改变源代码。结果，在本文中公开的一些实施例中，合约违反仅被看作可外部地恢复的状况106并且因此它们导致放弃。

操作系统中围绕应用编程接口(API)边界完成的大多数正确性检查都将防止编程器错误。操作系统针对不利的状况进行检查，并向调用者返回失败指示。调用者随后还进行一些检查以防操作失败。所有该检查相当于影响可读性、开发时间和得到的系统的性能的很多代码。

展示双重检查的典型C代码的示例如下：

BOOLM1(intx)

{

//该实现中的检查

if(x<0){

returnFALSE；

}

returnTRUE；

}

voidM2()

{

if(Ml(42)＝＝FALSE){

//调用者中的另一检查

}

}

在本文中公开的一些实施例中，代码永远都不会在本地推理出从合约违反中恢复，将该逻辑从所有程序和系统代码中消除在本质上减小了程序大小并改善了性能。

voidMl(intx)

requiresx>＝0//单个检查

{

}

voidM2()

{

Ml(42)；

}

如图3中所示，一些实施例实现具有放弃的受管运行时。受管语言提供安全措施以防止软件中的一些非预期行为。例如，类型安全性确保指针总是引用有效的强类型数据。在典型的受管环境(诸如Java或.NET)中，软件违反受管运行时的先决条件的尝试导致异常。例如，访问空指针或尝试写在阵列的边界之外将导致异常。

此外，受管语言有时还在程序执行内的任意点处注入失败。例如，在一些环境中，JIT编译器被用于编辑在运行中的代码，并且如果JIT编译器无法分派某个存储器，则它可在反映该事实的计算中注入异常。

该一般管理实际上暗示几乎受管程序中的任何语句都易遭受失败。任何指针访问都可导致空引用异常，任何阵列访问都可导致超出边界异常，且所执行的任何语句都可导致JIT编译器用完存储器。这使得它在实践上无法推理出复杂系统的行为。基本上，任何事务都可在任何时间由于多个不同原因中的一个或多个而失败。即使被设计成对失败进行补偿的代码也可在任何时间由于多个不同原因中的一个或多个而失败。

使用该方法，仅有可能设计出在正常使用时趋于正确的软件系统。然而，几乎无法设计出任何规模的可证实为正确的系统。

然而，相反，在本文中公开的一些实施例中，各实施例将对受管运行时的先决条件的违反看作与合约违反一样可严格地外部地恢复。当这样的违反发生时，它们不可被受影响的计算观察到，因为放弃被立即触发。

本文中公开的一些实施例处理具有放弃的存储器耗尽。存储器是计算环境中的有限资源。在常规系统中，用完存储器通常会被报告给尝试获得该存储器的软件。在本机语言(如C)中，这是通过返回空指针来实现的，而在受管语言中异常会被抛出。

在受管环境中编程通常会导致与在常规本机环境中体验到的非常不同的存储器分派模式。这是由以下事实造成的：对所分派的存储器块的生存期管理在受管代码中不是一个问题。结果，这趋于存在更频繁的分派点，并且分派趋于与本机代码中的相比更多的自组织。事实上，受管语言中的若干构造最终依据该语言或底层的虚拟机如何被实现而在非预期点处分派存储器，这使得编程器难以与要分派的失败竞争。

从用完存储器状况中恢复非常困难，并且想要这样做的代码通常会由于取消逻辑中的固有隐错而就地失败。在受管代码中，取消逻辑本身通常可尝试分派一些存储器，这也可失败。相反，在本文中公开的一些实施例中，各实施例将存储器耗尽看作为可外部地恢复的错误状况。当计算用完存储器时，它被放弃。

现在在以下示出用于可内部地恢复的错误的异常效果系统。作为通用规则，在失败不可能的情况下，写软件更容易。编程器不需要写任何容易出错的取消逻辑，而可写更直接的源代码。参考图2，编译器206还能够进行改善得到的经编译代码的质量的附加优化。

如前所述，在常规的受管环境中，几乎每一语句都可导致失败。因此非常难以推理出高度可靠的软件的创建，并且编译器206有要支持昂贵语义的负担。

相反，在本文中公开的一些实施例中，使用先前描述的机制，各实施例已系统地移除了可导致软件内的细粒度失败的状况中的大多数。相关联的错误状况中的大多数是经由外部恢复来处理的。所保留的是相对较小的可内部地恢复的错误状况的集合。

在给定无错误编程的益处的情况下，各实施例引入了将软件方法或块显式地注释为可能失败的能力。例如，如图2所示，各代码部分可被注释为可能失败204的代码。在本文中该暗示是没有被这样注释的软件可只是不会经历可内部地恢复的错误。由于可外部地恢复的错误显式地与程序的主逻辑分开地处理，各实施例现在具有使大型计算图完全没有任何错误逻辑的能力。这导致编程体验的显著简化，并导致经编译代码的质量改善的显著可能。例如，以下代码可通过抛出异常来指示M1可失败。当方法声明上不存在这样的注释时，该方法被认为是确实可靠的，

throwsvoidMl()

{

thrownewException("该方法失败")；

}

voidM2()

{

try{

tryMl0

}

catch(Exceptionex){

}

}

创建不会观察到导致放弃的失败的代码区域并实现要求可内部地恢复的错误的点被显式地注释的约束为后端编译器提供了通过避免传播异常所需的昂贵序列来产生更优良的机器代码的机会，从而改善了得到的程序的性能。

编译器206理解放弃的语义。编译器可利用以下事实：放弃立即停止执行现有范围中的指令以消除冗余的控制流。软件系统中的控制流表示处理器执行的指令序列。处理器具有指示要执行的下一指令的地址的指令指针。当该指令完成时，处理器自动增加指令指针以指示下一指令所在的接下来的存储器位置。存在用于更改控制流的某些特殊指令。这些指令是非条件分支、条件分支、函数调用、函数返回及其他。现代微处理器的流水线性质是使得在不存在修改该处理器的自然序列控制流的指令时这些处理器可快得多地执行代码序列。消除控制流指令可因此对微处理器的总吞吐量具有剧烈的影响。

各实施例还教导编译器206应当将放弃看作罕见事件，并且编译器可使用该信息通过将不被频繁使用的代码移到线外来相应地组织代码布局，因此改善了指令高速缓存效率。可将软件缺陷看作为差错(abberration)。因此，放弃在软件系统的生存期中是罕见事件。许多编译器优化依据某些代码序列为“热”而其他为“冷”的知识来被增强。在该系统中热代码序列被频繁执行，而冷代码不被频繁地执行。简档导向的优化在以下情况下是常用的实践：经编译的程序以诊断设置执行以便观察到代码的动态执行。基于这些观察，重新编译被测试的程序。这时，编译器认为热/冷信息是通过运行该程序以便组织它合适地生成的代码来获得的。简档导向的优化基本上都有缺陷，因为所收集的描述程序的执行模式的数据本质上是有限的，即仅表示程序的很小比例的可能执行。导致放弃的代码序列可被编译器系统地看作为冷代码。不像简档导向的优化，编译器可依赖于该信息在所有情况下总是正确的。

合约的使用从主代码路径中消除通常冗余的检查。在操作系统边界周围，通常检查API的实现中的各参数，并且该API的调用者作为整体检查API的失败。使用合约架构，调用者侧的检查完全是冗余的，并且不需要被写入。

异常效果系统使得编译器206能够精确地知道可能抛出异常并且一般易受到可内部地恢复的错误的影响的代码区域。作为结果，在生成被设计为永远都不会经历可内部地恢复的错误的代码时，编译器206可避免生成通常与异常处理相关联的更昂贵的代码。

以下讨论现涉及可以执行的多种方法以及方法动作。虽然用特定次序讨论或用以特定次序发生的流程图示出了各个方法动作，但除非明确规定或因为一动作依赖于另一动作在执行该动作之前完成而需要特定次序，否则不需要特定次序。

现在参考图4，示出了方法400。方法400可在计算环境中实施，并包括用于处理错误的动作。该方法包括标识包括多个显式地标识出的失败状况的集合(动作402)。例如，如图1所示，示出了可外部地恢复的状况106。这些被运行执行范围100的框架或其他实体在设计中显式地枚举出。

方法400进一步包括确定已发生了这些显式地标识出的失败状况中的一个或多个(动作404)。例如，特定的失败点可静态地规定它是什么类型的错误。换言之，代码可被注释为指示“如果在这里存在失败，则它总是为可外部地恢复的错误，而如果在那里存在错误，则它本质上是可内部地恢复的错误”。换言之，通常，发现点确定它是什么错误种类。

作为结果，方法400进一步包括停止预定的第一计算执行范围(动作406)，并向另一计算范围通知该失败状况(动作408)。例如，在图1中示出的示例中，可停止执行范围100，并且可向执行范围110(并且具体为代理108)通知该失败。外部范围可被配置以处理该失败状况。

在包括多个显式地标识出的失败状况的集合包括指示计算模块的静态不变式要求已被违反的失败状况的情况下，可实施方法400。例如，图1示出了约束集合120。这些约束可以是静态不变式要求的示例。约束的违反通常指示软件中的隐错，该隐错最好由外部代理108来处理。

方法400可进一步包括向编程器用户标识包括多个显式地标识出的失败状况的集合，以向该编程器用户指示可导致第一计算执行范围的失败的失败状况。具体地，编程器可能够访问将导致由外部代理处理的失败的状况列表。因此，编程器可在考虑这个的情况下对应用进行编程，并由此优化应用以用于这种类型的错误处理。具体地，编程器可能不需要在应用中创建这么多的错误处理代码，因为编程器知道这样的错误将由外部代理来处理。

方法400可进一步包括向编译器标识包括多个显式地标识出的失败状况的集合，以向该编译器指示可导致第一计算执行范围的失败的失败状况。例如，如图2所示，编译器206可知晓可在范围100处内部地失败204的代码。编译器206可随后基于此来对如何编译一组代码进行优化。例如，一些实施例可包括编译器以经优化的方式基于标识出的集合来编译预定的第一计算执行范围。在一些实施例中，以经优化的方式基于标识出的包括多个显式地标识出的失败状况的集合来编译预定的第一计算执行范围包括通过将不被频繁使用的代码移到线外来组织该预定的第一执行范围的代码布局，以改善高速缓存效率。替换地或另选地，以经优化的方式基于标识出的包括多个显式地标识出的失败状况的集合来编译预定的第一计算执行范围包括基于编译器对导致停止预定的第一计算执行范围的状况的知识来消除冗余的控制流。

现在参考图5，示出了另一方法500。方法500可在计算环境中实施，并包括用于处理错误的动作。该方法包括标识包括多个显式地标识出的失败状况的集合(动作502)。

方法500进一步包括确定已发生了不在该包括多个显式地标识出的失败状况的集合中的错误状况(动作504)。因此，与以上所示的方法400相反，方法500叙述了不在预定义的集合中的错误状况的元素。

作为结果，方法500进一步包括停止预定的第一计算执行范围(动作506)，并向另一计算范围通知该失败状况(动作508)。如图1所示，当错误发生，但该错误不在预定义的错误状况集合中时，可停止范围100，并通知代理108。

方法500可进一步包括确定已发生了在包括多个显式地标识出的失败状况的集合中的另一错误状况，这是在第一计算执行范围内部处理该其他错误状况的结果。例如，错误状况可在该范围100被内部地处理。

方法500可进一步包括向编程器用户标识包括多个显式地标识出的失败状况的集合，以向该编程器用户指示不将导致第一计算范围失败的状况。

方法500可进一步包括向编译器标识包括多个显式地标识出的失败状况的集合，以向该编译器指示确实会导致第一计算执行范围的失败的失败状况。这可有助于编程器高效地创建应用代码。

方法500可进一步包括编译器以经优化的方式基于标识出的包括多个显式地标识出的失败状况的集合来编译预定的第一计算执行范围。以经优化的方式基于标识出的包括多个显式地标识出的失败状况的集合来编译预定的第一计算执行范围可包括通过将不被频繁使用的代码移到线外来组织该预定的第一执行范围的代码布局，以改善高速缓存效率。替换地或另选地，以经优化的方式基于标识出的包括多个显式地标识出的失败状况的集合来编译预定的第一计算执行范围可包括基于编译器对导致停止预定的第一计算执行范围的状况的知识来消除冗余的控制流。

此外，各种方法可由包括一个或多个处理器和诸如计算机存储器等计算机可读介质的计算机系统来实施。具体而言，计算机存储器可存储计算机可执行指令，这些指令在由一个或多个处理器执行时使得诸如各实施例中所述的各个动作等各种功能被执行。

本发明的各实施例可以包括或利用包含计算机硬件的专用或通用计算机，这将在下文中更详细地讨论。本发明范围内的各实施例还包括用于承载或存储计算机可执行指令和/或数据结构的物理和其他计算机可读介质。这样的计算机可读介质可以是可由通用或专用计算机系统访问的任何可用介质。存储计算机可执行指令的计算机可读介质是物理存储介质。承载计算机可执行指令的计算机可读介质是传输介质。由此，作为示例而非限制，本发明的各实施例可包括至少两种显著不同的计算机可读介质：物理计算机可读存储介质和传输计算机可读存储介质。

物理计算机存储介质包括RAM、ROM、EEPROM、CD-ROM或其他光盘存储(如CD、DVD等)、磁盘存储或其他磁存储设备、或可用于存储计算机可执行指令或数据结构形式的所需程序代码装置且可由通用或专用计算机访问的任何其他介质。

“网络”被定义为允许在计算机系统和/或模块和/或其他电子设备之间传输电子数据的一个或多个数据链路。当信息通过网络或另一个通信连接(硬连线、无线、或者硬连线或无线的组合)传输或提供给计算机时，该计算机将该连接适当地视为传输介质。传输介质可包括可用于携带计算机可执行指令或数据结构形式的所需程序代码装置且可由通用或专用计算机访问的网络和/或数据链路。以上介质的组合也被包括在计算机可读介质的范围内。

此外，在到达各种计算机系统组件之后，计算机可执行指令或数据结构形式的程序代码装置可从传输计算机可读介质自动转移到物理计算机可读存储介质(或者相反)。例如，通过网络或数据链路接收到的计算机可执行指令或数据结构可被缓存在网络接口模块(例如，“NIC”)内的RAM中，然后最终被传送到计算机系统RAM和/或计算机系统处的较不易失性的计算机可读物理存储介质。因此，计算机可读物理存储介质可被包括在同样(或甚至主要)利用传输介质的计算机系统组件中。

计算机可执行指令包括，例如使通用计算机、专用计算机、或专用处理设备执行某一功能或某组功能的指令和数据。计算机可执行指令可以是例如二进制代码、诸如汇编语言之类的中间格式指令、或甚至源代码。尽管用结构特征和/或方法动作专用的语言描述了本主题，但可以理解，所附权利要求书中定义的主题不必限于上述特征或动作。更具体而言，上述特征和动作是作为实现权利要求的示例形式而公开的。

本领域的技术人员将理解，本发明可以在具有许多类型的计算机系统配置的网络计算环境中实践，这些计算机系统配置包括个人计算机、台式计算机、膝上型计算机、消息处理器、手持式设备、多处理器系统、基于微处理器的或可编程消费电子设备、网络PC、小型计算机、大型计算机、移动电话、PDA、寻呼机、路由器、交换机等等。本发明也可在其中通过网络链接(或者通过硬连线数据链路、无线数据链路，或者通过硬连线和无线数据链路的组合)的本地和远程计算机系统两者都执行任务的分布式系统环境中实施。在分布式系统环境中，程序模块可以位于本地和远程存储器存储设备二者中。

本发明可具体化为其他具体形式而不背离其精神或特征。所描述的实施例在所有方面都应被认为仅是说明性而非限制性的。因此，本发明的范围由所附权利要求书而非前述描述指示。落入权利要求书的等效方案的含义和范围内的所有改变都被权利要求书的范围所涵盖。

Claims (7)

1.一种在计算环境中处理错误的方法，所述方法包括：

标识包括多个显式地标识出的失败状况的集合；

确定已发生了所述显式地标识出的失败状况中的一个或多个；以及

作为结果，停止预定的第一计算执行范围，并向另一计算范围通知该失败状况。

2.如权利要求1所述的方法，其特征在于，所述包括多个显式地标识出的失败状况的集合包括指示计算模块的静态不变式要求已被违反的失败状况。

3.如权利要求1所述的方法，其特征在于，进一步包括向编程器用户标识所述包括多个显式地标识出的失败状况的集合，以向所述编程器用户指示能导致所述第一计算执行范围的失败的失败状况。

4.如权利要求1所述的方法，其特征在于，进一步包括向编译器标识所述包括多个显式地标识出的失败状况的集合，以向所述编译器指示能导致所述第一计算执行范围的失败的失败状况。

5.如权利要求4所述的方法，其特征在于，进一步包括所述编译器以经优化的方式基于所述标识出的包括多个显式地标识出的失败状况的集合来编译所述预定的第一计算执行范围。

6.如权利要求5所述的方法，其特征在于，以经优化的方式基于所述标识出的包括多个显式地标识出的失败状况的集合来编译所述预定的第一计算执行范围包括通过将不被频繁使用的代码移到线外来组织所述预定的第一执行范围的代码布局以改善高速缓存效率。

7.如权利要求5所述的方法，其特征在于，以经优化的方式基于所述标识出的包括多个显式地标识出的失败状况的集合来编译所述预定的第一计算执行范围包括基于所述编译器对导致停止所述预定的第一计算执行范围的状况的知识来消除冗余的控制流。