通過最小化差錯恢復邏輯來改善軟件系統(tǒng)的制作方法
【專利說明】通過最小化差錯恢復邏輯來改善軟件系統(tǒng)
[0001] 背景
[0002] 計算機和計算系統(tǒng)已經影響了現(xiàn)代生活的幾乎每個方面。計算機通常涉及工作、 休閑、保健、運輸、娛樂、家政管理等。計算機功能通常是計算系統(tǒng)執(zhí)行軟件代碼的結果。
[0003] 非常大部分的現(xiàn)代軟件代碼旨在發(fā)現(xiàn)錯誤狀況、報告錯誤狀況和從錯誤狀況中恢 復。在現(xiàn)實世界場景中，錯誤狀況相對罕見并且通常難以模擬，然而程序員投入了大量的資 源來處理它們。
[0004] 在軟件系統(tǒng)內，差錯恢復代碼中存在與這些系統(tǒng)中的全部代碼相比不成比例的隱 錯數(shù)。這與以下事實有關：錯誤狀況通常難以模擬，結果通常保持未被測試，直到消費者遇 到了該領域的底層問題。不合適的錯誤恢復邏輯可導致復合錯誤，并最終導致崩潰和數(shù)據(jù) 破壞。
[0005] 常規(guī)的軟件系統(tǒng)混合有不同類型的錯誤狀況，并提供單個機制來處理這些錯誤狀 況。這種一致性表面上很吸引人，因為它允許開發(fā)者以單個一致的方式為系統(tǒng)推理出錯誤 狀況。不幸地是，這種一致性使錯誤的定性差異模糊。
[0006] 在此要求保護的主題不限于解決任何缺點或僅在諸如上述環(huán)境中操作的各個實 施例。相反，提供該背景僅用以示出在其中可實踐在此描述的部分實施例的一個示例性技 術領域。
[0007] 概述
[0008] -個實施例可以是具有用于處理錯誤的動作的在計算環(huán)境中實施的方法。該方法 包括標識包括多個顯式地標識出的失敗狀況（failure condition)的集合。該方法進一步 包括確定已發(fā)生了這些顯式地標識出的失敗狀況中的一個或多個。結果，該方法進一步包 括停止預定的第一計算執(zhí)行范圍，并向另一計算范圍通知該失敗狀況。
[0009] -替換實施例可在計算環(huán)境中實施，并包括用于處理錯誤的方法。該方法包括標 識包括多個顯式地標識出的失敗狀況的集合。該方法進一步包括確定已發(fā)生了不在該包括 多個顯式地標識出的失敗狀況的集合中的錯誤狀況。作為結果，該方法進一步包括停止預 定的第一計算執(zhí)行范圍，并向另一計算范圍通知該錯誤狀況。
[0010] 提供本概述是為了以精簡的形式介紹將在以下詳細描述中進一步描述的一些概 念。本概述并不旨在標識出所要求保護的主題的關鍵特征或必要特征，也不旨在用于幫助 確定所要求保護的主題的范圍。
[0011] 將在以下的描述中闡述另外的特征和優(yōu)點，并且部分特征和優(yōu)點可從該描述中顯 而易見，或者可從本文教導的實踐中獲知。本發(fā)明的特征和優(yōu)點可以通過在所附權利要求 中特別指出的手段和組合來實現(xiàn)并獲取。本發(fā)明的特征將從以下描述和所附權利要求書中 變得完全顯而易見，或者可通過如下所述對本發(fā)明的實踐而獲知。
[0012] 附圖簡述
[0013] 為了描述可獲得本主題的上述和其它優(yōu)點和特征的方式，將通過參考附圖中示出 的本主題的具體實施例來呈現(xiàn)以上簡要描述的本主題的更具體描述。應該理解，這些附圖 僅描繪了各典型實施例，因此其不應被認為是對范圍的限制，各實施例將通過使用附圖用 附加特征和詳情來描述并解釋，在附圖中：
[0014] 圖1示出了一計算執(zhí)行范圍；
[0015] 圖2示出了代碼主體和用編譯器編譯該代碼；
[0016] 圖3示出了受管代碼系統(tǒng)；
[0017] 圖4示出了處理錯誤的方法；以及
[0018] 圖5示出了處理錯誤的另一個方法。
[0019] 詳細描述
[0020] 各實施例將全部失敗狀況顯式地劃分成"預期"失敗狀況和"非預期"失敗狀況。 軟件被預期從預期失敗就地恢復，而非預期失敗被在外部處理。這樣做是因為依據(jù)定義這 些失敗是非預期的，并且軟件沒有為這些失敗做好準備。各實施例可包括多個不同的機制 中的一者或多者，以使得軟件環(huán)境有可能系統(tǒng)地標識出哪些失敗是預期的及哪些失敗不是 預期的，使得可發(fā)生正確的處置。參考圖1，各實施例可將軟件執(zhí)行范圍100內發(fā)生的錯誤 狀況的整個集合102劃分成兩種類型，并提供用于處理每一種類型的專用機制。在這樣做 時，各實施例得到范圍從改善的正確性到改善的性能的多個益處。參考圖1，識別出的兩種 寬泛類型的錯誤狀況的實施例為可內部地恢復的狀況104和可外部地恢復的狀況106。
[0021] 可內部地恢復的狀況104是軟件執(zhí)行范圍100能夠可靠地發(fā)現(xiàn)并從本地計算范圍 內恢復的錯誤狀況。這些錯誤源自以下兩個寬泛的源：1/〇失敗和語義失敗。
[0022] 可外部地恢復的狀況106是各實施例確定軟件裝備不良無法就地處理并因此由 外部代理108來處理的狀況?？赏獠康鼗謴偷腻e誤狀況一般源自以下兩個寬泛的源：軟件 缺陷（即，隱錯）和元失?。ɡ?，無法分派存儲器）。元失敗是與計算的語義不直接相關 并作為該計算在其中執(zhí)行的虛擬環(huán)境中的約束的結果的失敗。例如，計算預期具有它可將 局部變量推送到其上的棧。如果虛擬環(huán)境向棧的深度施加了限制，則計算一般無法預測該 限制將何時發(fā)生，并且可能在到達這樣的限制時沒有恢復路徑。類似地，計算通常預期能夠 分派存儲器，并且無法獲得新的存儲器是元失敗。
[0023] 在這樣的錯誤發(fā)生時，其中發(fā)生了該錯誤的計算范圍100已在某種程度上受損， 并因此無法注意到該錯誤狀況并從其恢復。由此，將錯誤處理留給在未受損范圍110中操 作的外部代理108。例如，在無法分派存儲器的情況下，請求無法分派存儲器的原始計算范 圍100中的代理開始恢復算法通?？蓪е略摯韲L試分派存儲器來執(zhí)行該恢復算法。這沒 有多大意義。相反，能夠分派存儲器或者已經分派了用于恢復的存儲器的外部代理108可 能夠更好地處理該錯誤。
[0024] 對"用完存儲器"的常見響應事實上是完全放棄該操作。盡管在常規(guī)的系統(tǒng)中經 歷用完存儲器狀況的代碼必定包含非常大量的錯誤檢查和昂貴的用于在失敗情況下進行 清理的取消邏輯，在本文中的實施例各中，代碼可被編寫就好像分派將一直成功一樣。如果 分派確實失敗了，則各實施例立即停止運行任意更多代碼，并服從于另一上下文，該另一上 下文可隨后將整個操作看作已經失敗。
[0025] 在常規(guī)系統(tǒng)中，存在提供對錯誤狀況進行根本不健全的本地運行時檢測、報告和 恢復的非常大量的代碼。該代碼可能會偶爾成功，但它通常是無用的練習。本文中公開的 一些實施例系統(tǒng)地放棄該代碼，從而導致沒有容易出錯的取消邏輯的負擔的短的多的源代 碼。
[0026] 各實施例組合多個技術來將錯誤狀況系統(tǒng)地劃分成以上兩種類型，并使得編程器 能夠顯式地推理出哪些代碼可能失敗以及哪些代碼不可能失敗。通過系統(tǒng)地應用這些技 術，各實施例實現(xiàn)了相當多的正確性、性能和開發(fā)時間益處。
[0027] 以下示出了本文中公開的各個實施例中的一個或多個的各方面中的幾個方面的 簡要概述。如上所述的各實施例可實現(xiàn)錯誤類型劃分。各實施例可系統(tǒng)地將所有錯誤狀況 分成可內部地恢復的錯誤104和可外部地恢復的錯誤106,并向每一者顯式地應用不同的 處置策略。
[0028] 各實施例可實現(xiàn)在本文中被稱為放棄的概念。放棄是立即掛起被破壞的范圍（諸 如例如軟件執(zhí)行范圍100)內的計算的執(zhí)行的機制。操作系統(tǒng)進程用作典型的放棄上下文 范圍，但如以下更詳細示出的，其他進程是可能的。當放棄發(fā)生時，沒有在該計算的范圍內 的附加代碼執(zhí)行，從而防止引入進一步的破壞，并改為允許外部代理來嘗試進行恢復。
[0029] 各實施例可實現(xiàn)具有放棄的整體合約。系統(tǒng)可定義基于合約的設計方法。本文中 公開的一些實施例在操作系統(tǒng)中引入對合約的使用，從而除了使用操作系統(tǒng)實現(xiàn)內的合約 外，還利用用于定義所有操作系統(tǒng)接口的合約。合約定義了邏輯代理要求的靜態(tài)不變式要 求集合。例如，合約可定義到邏輯代理的可接受的輸入。如果這些靜態(tài)不變式要求中的任 一沒有被滿足，則該合約被違反。各實施例通過將合約違反看作合約所適用的違反者或邏 輯代理無法校正的情況來擴展經典的合約模型，這使得這樣的違反進入到可外部地恢復的 錯誤106中。
[0030] 各實施例可實現(xiàn)具有放棄的受管運行時。盡管常規(guī)的受管語言系統(tǒng)（諸如Java 和C#)依賴于異常來報告運行時級別的錯誤（諸如，界外陣列訪問、空解除引用或用完存儲 器的狀況），但各實施例將所有這樣的事件都看作對運行時的合約先決條件的違反，從而導 致放棄。
[0031] 各實施例實現(xiàn)具有放棄的存儲器耗盡。盡管常規(guī)系統(tǒng)嘗試向編程器系統(tǒng)地報告所 有形式的存儲器耗盡，但本文中公開的一些實施例將這樣的事件看作不可內部地恢復，并 因此它們僅是導致當前計算的放棄的可外部地恢復的錯誤106。
[0032] 各實施例可為可內部地恢復的錯誤狀況實現(xiàn)異常效果系統(tǒng)。通過使用以上機制， 各實施例可顯著地減少需要針對可內部地恢復的錯誤狀況的恢復邏輯的軟件量。這使得 有可能引入效果系統(tǒng)來使得編程器和編譯器清楚哪些方法和代碼塊可經歷可恢復的錯誤 (如圖2中不能失敗的代碼202所示的）以及哪些方法和代碼塊不能經歷可恢復的錯誤（如 圖2所示的能失敗的代碼204所示的）。在一些實施例中，各方法和代碼塊可注釋有指示 它是否可內部地恢復的元數(shù)據(jù)。這使得系統(tǒng)和應用代碼內的大型調用圖能夠在假定沒有內 部錯誤的情況下被寫出。這使得受影響的代碼寫和推理起來容易的多，并且改善了用于發(fā) 現(xiàn)軟件中可導致可外部地恢復的錯誤狀況106的缺陷的靜態(tài)分析能力。以下示出了代碼注 釋示例。該示例示出了各方法可被聲明為拋出異常。在沒有被注釋時，一方法不能拋出異 常并因此沒有經歷到或引入任何可內部地恢復的錯誤。結果，對這一方法的調用被看作不 易出錯，并且不需要錯誤恢復邏輯。然而，M2被注釋為拋出，并因此對這一方法的調用必定 在"try (嘗試）"關鍵詞之前以向編程器指示潛在的失敗點。此外，由于該調用可失敗，錯 誤恢復邏輯是必須的，該錯誤恢復邏輯被包含在catch (捕捉）子