很容易假設一個系統在現場表現得和在工程臺上一樣完美。在開發過程中，嵌入式軟件是在最好的條件下編寫的。嵌入式開發人員知道，或者至少有他們自己的系統應該如何工作的概念。 事情通常運行得相當順利，但隨著成千上萬的設備開始進入用戶手中，意外發生和錯誤發生的可能性在統計上變得很可能。在今天的文章中，讓我們探討開發人員編寫可以處理意外錯誤的軟件所需的策略。

　　策略 #1 – 不斷考慮可能出現的問題

　　開發人員需要部署以處理錯誤的第一個策略是在編寫每一行代碼時積極質疑可能出現的問題。例如，當我為如下函數編寫實現時：

　　void Dio_WriteChannel(DioChannel_t Channel, bool state)

　　{

　　// Additional code goes here

　　}

　　我問自己幾個問題：

　　如果 Channel 參數超出范圍會發生什么?

　　該函數應該返回錯誤代碼還是成功標志?

　　如何驗證所需的通道狀態是否已更改?

　　如果狀態試圖改變但不能改變，我該怎么辦?

　　內存是否會損壞，以至于我的bool狀態變量不是真假? 如果是這樣，我該如何處理?

　　斷言是否足以在開發時檢查邊界條件，還是應該對參數進行實時檢查?

　　這是很多問題，或者諸如簡單通用代碼塊之類的問題，我們真的還沒有開始填寫細節!但是，如果你希望能夠處理錯誤，則必須不斷地質疑代碼以及可能出現的問題。

　　策略 #2 – 使用 TODO 記錄疑慮和問題

　　隨著軟件的開發，有時問題多于目前的答案。在上面的示例中，可能還沒有關于如何處理返回錯誤的答案。暫時就這樣真的很容易，但是隨著其他問題會出現，這個問題就會被遺忘在喧囂中。

　　大多數現代 IDE 都會有自定義標簽，可以從代碼中提取這些標簽來創建一個列表，例如使用 TODO。這些將顯示為信息性消息。如果有需要處理的錯誤，但我不知道如何處理，我會使用 TODO。如果有一個實現，但我想查看它，我可能會使用 TODO，但也可能使用其他一些我可以輕松搜索代碼的關鍵字。需要注意不要讓 TODO 信息消息過載，否則它會變得太嘈雜，但我們也希望確保我們不會丟失我們的問題或問題。 (是的，可以使用外部跟蹤器，但我發現將其與代碼一起保存要容易得多，因此代碼審查員和其他嵌入式開發人員可以輕松地看到它)。

　　策略#3 – 總是抱著“以后會改的態度”

　　現在是修復、記錄或實施錯誤檢查的最佳時機?？偸怯心承﹩栴}正在引起開發人員的注意，雖然我們總是想返回并添加錯誤處理，但卻總是在拖延!

　　一旦某些事情似乎對管理層有用，就該著手處理下一個緊迫問題了。如果它有效，你為什么要在它上面投入更多的時間來減少回報?管理層沒有意識到你沒有包括錯誤檢查或實施中存在巨大的漏洞!如果產品需要健壯性，請不要嘗試稍后添加它，或者相信你可以稍后再返回并修復它。

　　結論

　　嵌入式開發人員編寫軟件的方式決定了他們的系統是否能夠從錯誤中優雅地恢復，關鍵是要有正確的開發態度，在編寫軟件時考慮可能出現的問題并實施恢復機制。為了更好地處理錯誤，請處理當前可能出現的問題，否則將永遠無法處理。