error = 0 的程式是不存在的，怎樣收集和處理程式中的錯誤？怎樣更好地利用錯誤資訊的收集和反饋來協助程式的除錯？怎樣讓產品發布後，使用者能夠反饋出更有價值的問題資訊？這些問題是本文將要涉及的，最近對自己所做專案中的錯誤處理機制做了一些總結與思考，故在此討論，希望對大家有所幫助。
目前，按照我個人的理解，軟體中的錯誤收集和反饋方式主要有如下幾種：
第一種方式：使用常用的資訊輸出語句。
對於控制台程式，可以使用 printf 語句或者 std::cout 將錯誤資訊列印出來；對於mfc程式，可以使用 trace 巨集，將錯誤資訊輸出到 output 視窗，或者使用 messagebox直接彈出對話方塊將錯誤資訊告知使用者 。
這些處理策略往往針對於「互動性」的**段，可以實現 實時反饋錯誤資訊，以供使用者實時地進行處理，以免後面產生更大的錯誤。
第二種方式：使用錯誤日誌方式
思想：將程式中的所有錯誤資訊輸出到錯誤日誌檔案中，這樣有以下這些好處：
1. 當程式發布後，客戶在使用中遇到問題後，可以直接將錯誤日誌傳送給程式設計師，將極大地方便了問題的定位及原因的分析。
2. 便於除錯多執行緒或者涉及網路通訊等複雜的程式，因為在這樣的程式中，設定斷點的除錯方式非常地不方便，一旦暫停在斷點處，往往為引起執行緒異常或者 網路連線斷開等問題，極大影響了除錯的效率。如果將錯誤資訊列印到檔案中，錯誤描述詳細豐富一些，可以極大地提高除錯的效率。
3. 便於程式進行大規模的效能測試。例如：c/s模式的系統，進行100個客戶端對伺服器的訪問測試，使用這種錯誤收集策略可以方便地通過分析錯誤日誌檔案來推測系統的效能。
下面思考這樣乙個問題：很多軟體的設計上都有乙個類似tcp/ip協議的應用層的模組，該模組一般是直接與客戶端互動的一層，它隔離了核心**模組與客戶端的耦合，那麼，對於這樣一種層次結構比較深設計方案，最底層發生的錯誤資訊怎樣傳遞到最上層？每一層都提供獲取錯誤資訊的介面？這樣開銷太大，也往往不夠理想，那該怎樣處理呢？
我想應該主要有以下兩種處理策略，也就是我即將引出的錯誤收集和反饋的第三種和第四種策略：
第三種方式：異常機制
這裡說說c++的異常處理機制，它是乙個用來有效地處理執行錯誤的非常強大且靈活的工具，它提供了更多的彈性、安全性和穩固性，克服了傳統方法所帶來的問題.
異常的丟擲和處理主要使用了以下三個關鍵字： try、 throw 、 catch 。
丟擲異常、捕獲異常 ，這些是c++提供的極其方便地處理異常策略，可以實現在最底層丟擲異常，由最上層捕獲，並且處理。
說實話，c++異常機制的確是一種處理錯誤和異常的很好的策略，如果需要使用該機制，需要從軟體架構和設計時就要開始考慮，一旦軟體結構和**寫到一定程度後，再引入異常機制將很難達到很好的效果。其實，要想用好c++異常機制，不是一件很容易的事，特別是對於專案組裡面有大量新人的時候，故使用成本還是挺高的。
關於c++異常機制很多c++書籍都有介紹，我也不在此贅述，本部落格也有一篇c++異常機制的入門示例**，有興趣可以看看:
第四種方式：getlasterror模式
經常開發windows程式的人應該都了解，windows程式有乙個api：getlasterror，它其實代表著一種錯誤收集處理機制。
當乙個windows函式檢測到乙個錯誤時，它會使用乙個稱為執行緒本地儲存器(thread-localstorage)的機制。當函式返回時，它的返回值為flase就能指明乙個錯誤已經發生。若要確定這是個什麼錯誤，可以呼叫getlasterror函式來獲取：該函式只返回執行緒的32位錯誤**。
winerror.h標頭檔案包含了microsoft公司定義的錯誤**的列表。
當windows函式執行失敗時，應該立即呼叫getlasterror函式。如果呼叫另乙個windows函式，它的值很可能被改寫。
visual studio還配有乙個小的實用程式，稱為error lookup.
如果在編寫的應用程式中發現乙個錯誤，可能想要向使用者顯示該錯誤的文字描述。windows提供了乙個函式，可以將錯誤**轉換成它的文字描述。該函式稱為formatmessage。
以上就是getlasterror模式的介紹，可以簡單地把它想象成為這樣一種模式：有乙個全域性的變數，可以用來存放32位錯誤**，一旦windows函式執行失敗，就將錯誤**賦值給這個全域性的變數，每當呼叫getlasterror，則將該錯誤**返回出來以供外部分析原因。
其實，我們自己也可以實現這樣乙個getlasterror模式的錯誤收集機制，收集整個程式中最新的錯誤資訊，供上層及時呼叫查詢，定義自己的錯誤**和錯誤描述資訊串，那麼，怎樣才能更好地實現屬於自己的類似的錯誤收集反饋機制呢？怎樣使它具有更好地移植性、健壯性（支援多執行緒等）和易擴充套件性（加入新的錯誤**和資訊）呢？我將在後面的文章中介紹我的思考和設計。
android 官方文件中的一些錯誤收集
1,intents and intent filters 中的 說明 for example,in the following uri,content the scheme is content the host is com.example.project the port is 200 and ...
軟體開發中的30個錯誤
1.不理解使用者的需求。缺乏使用者提出需求，或者根本就不問。2.低估專案的規模。3.快速通過計畫編制過程，或者沒有計畫編制過程。嚴重地編碼優先，計畫靠後！4.沒有盡早的 經常性地測試，或者根本就不測試。並且養成如此習慣。5.選擇很 酷 的方法學。6.不使用方 7.讓軟體開發者執行軟體開發專案。8.盲...
《快速軟體開發》讀後感 軟體開發中的典型錯誤
人員方面 1.挫傷積極性 2.人員素質低 3.對有問題的員工失控 4.英雄主義 5.專案後期加入人員 6.辦公環境擁擠嘈雜 7.開發人員與客戶之間發生摩擦 8.不現實的預期 9.缺乏有效的專案支援 10.缺乏各種角色的齊心協力 11.缺乏使用者介入 12.政治高於物質 13.充滿想象 過程方面 14...