《Design by Contract for Embedded Software》 翻譯

原文: Design by Contract for Embedded Software (state-machine.com)
Design by Contract is the single most effective programming technique for delivering high-quality code. Here you can learn what the Design by Contract programming philosophy is, what can it do for you, and why should all embedded software developers care.

契約式設計是交付高質量代碼的一種有效的編程技術 。在這里,你可以了解到什么是契約式設計的編程理念,它能為你做什么,以及為什么所有的嵌入式軟件開發者都應該關注它 。
Errors versus Exceptional Conditions錯誤 VS 異常
While embedded systems come with their own set of complexities, they also offer many opportunities for simplifications compared to general-purpose computers. Dealing with errors and exceptional conditions provides perhaps the best case in point. Just think, how many times have you seen embedded software terribly convoluted by attempts to painstakingly propagate an error through many layers of code, just to end up doing something trivial with it, such as performing a system reset?
雖然嵌入式系統有其自身的復雜性,但與通用計算機相比 , 它們也提供了許多簡化的機會 。處理錯誤(error)和異常情況(exception)可能是最好的例子 。試想一下,你有多少次看到嵌入式軟件試圖通過分析一層層的代碼艱難的把一個層層傳播下來的錯誤捕獲 , 然而由于系統的復雜性 , 最終只能做一些微不足道的事情去應對,比如執行系統復位?
By error (known otherwise as a “bug”), I mean a persistent defect due to a design or implementation mistake (e.g., overrunning an array index or writing to a file before opening it). When your software has a bug, typically, you cannot reasonably “handle” the situation. You should rather concentrate on detecting (and ultimately fixing) the root cause of the problem. This situation is in contrast to the exceptional condition, which is a specific circumstance that can legitimately arise during the system lifetime but is relatively rare and lies off the main execution path of your software. In contrast to an error, you need to design and implement a recovery strategy that handles the exceptional condition.
所謂錯誤(以其他方式稱為 "bug"),我指的是由于設計或實現上的錯誤(例如,數組越界或在打開文件之前寫入文件)導致的持續缺陷 。當你的軟件有一個 bug 時,通常,你不能合理地 "處理 "這種情況 。你應該專注于檢測(并最終修復)問題的根源 。這種情況與異常 (特殊情況)相反 , 異常是指在系統生命周期內可以合法地出現的特定情況,但相對罕見,并且不在你軟件的主要執行路徑上 。與錯誤相比,你需要設計和實施一個處理異常的恢復策略 。
As an example, consider dynamic memory allocation. In any type of system, memory allocation with malloc() (or the C++ new operator) can fail. In a general-purpose computer, a failed malloc() merely indicates that, at this instant the operating system cannot supply the requested memory. This can happen easily in a highly dynamic, general-purpose computing environment. When it happens, you have options to recover from the situation. One option might be for the application to free up some memory that it allocated and then retry the allocation. Another choice could be to prompt the user that the problem exists and encourage them to exit other applications so that the current application can gather more memory. Yet another option is to save data to the disk and exit. Whatever the choice, handling this situation requires some drastic actions, which are clearly off the mainstream behavior of your application. Nevertheless, you should design and implement such actions because in a desktop environment, a failed malloc() must be considered an exceptional condition.
我們以動態內存分配作為一個例子 。在任何類型的系統中 , 用 malloc()(或 C++的 new 操作符)分配內存都可能失敗 。在通用計算機中,一個失敗的 malloc() 僅僅表明,在這一時刻,操作系統不能提供所要求的內存 。在一個高度動態的通用計算環境中,這種情況很容易發生 。當它發生時,你可以選擇從這種情況下恢復 。一個選擇可能是讓應用程序釋放它所分配的一些內存,然后重新嘗試分配 。另一個選擇可能是提示用戶問題的存在,并鼓勵他們退出其他應用程序,以便當前的應用程序可以收集更多的內存 。然而,另一個選擇是將數據保存到磁盤并退出 。不管是什么選擇 , 處理這種情況需要一些激烈的行動 , 這顯然是不符合你的應用程序的主流行為 。然而,你應該設計并實現這樣的動作,因為在桌面環境中,malloc () 失敗必須被視為一種異常 。

推薦閱讀