2008-11-25 49 views
4

理論上,最終用戶不應該看到內部錯誤。但實際上,理論和實踐有所不同。所以問題是向最終用戶展示什麼。現在,對於完全不懂技術的用戶,您希望儘可能少地展示(「點擊這裏提交bug報告」類型的東西),但對於更高級的用戶,他們會想知道是否存在如果它已經知道了一段時間,所以你想包括一些有關什麼是錯誤的信息。內部錯誤標記

經典方式做到這一點是或者與文件名斷言:行號或與同一堆棧跟蹤。現在這對開發者來說很好,因爲它指出了他在這個問題上的正確性。然而它對用戶有一些重大的缺點,特別是它非常神祕(例如不友好)並且代碼改變會改變錯誤信息(谷歌搜索錯誤只適用於該版本)。

我有我打算寫,我想解決這些問題的程序。我想要的是一種將唯一標識附加到每個斷言的方式,以便在斷言周圍編輯代碼不會改變它。 (例如,如果我將其剪切/粘貼到另一個文件,我希望顯示相同的信息)任何想法?

一個釘我想的是有錯誤的枚舉,但如何確保他們永遠不會在多個地方使用? (注意:對於這個問題,我是只能查看由編碼錯誤引起的錯誤,而不是合理地發生錯誤輸入的錯誤,OTOH這些錯誤可能對整個社區都有一定的意義。)

(注2:有問題的程序會在用戶的系統上運行的命令行應用程序,但再一次,這只是我的情況)

(注3:目標語言是DI'm very willing潛入meta-programming。歡迎其他語言回答!)

(注意4:我明確地想要不使用實際的代碼位置,而是用錯誤的某種符號名稱。這是因爲如果代碼是在幾乎任何方式改變,代碼位置改變。)

回答

1

編寫一個腳本來grep您的整個源代碼樹,以使用這些錯誤代碼,然後抱怨如果有重複。作爲單元測試的一部分運行該腳本。

+0

好回落,但我寧願有這種錯誤打破構建或更快的反饋。 – BCS 2008-11-25 20:10:42

2

有趣的問題。我多次使用過的一個解決方案是:如果這是一個致命錯誤(非致命錯誤應該讓用戶有機會糾正輸入,例如),我們生成一個包含大量相關信息的文件:請求變量,頭文件,內部配置信息和完整的回溯以供以後調試。我們將它存儲在一個生成唯一文件名的文件中(並以時間爲前綴)。

對於用戶來說,我們提出了一個網頁,其中解釋說,發生了不可恢復的錯誤,並要求他們包括文件名作爲參考,如果他們想報告的bug。從違規請求的上下文中更輕鬆地調試所有這些信息。

在PHP的debug_backtrace()函數是用於這個非常有用的。我相信你的平臺有相同的功能。

還記得送相關HTTP標頭:大概是:HTTP/1.1 500內部服務器錯誤

由於錯誤報告文件的可感知的格式,它也可以分析用戶所沒有報告的錯誤。

+0

另外,考慮像進入這個文件的內存記錄器的東西。 – 2008-11-25 20:00:23

+0

不幸的是,我沒有使用該語言的跟蹤系統:( – BCS 2008-11-25 20:08:09

1

我對你的目標語言一無所知,但這是一個有趣的問題,我已經給了一些想法,我想增加我的兩分錢。

我的感覺一直是,對於硬錯誤和內部錯誤的信息應儘可能有用,以便開發人員識別問題&快速修復它。大多數用戶甚至不會看到這個錯誤消息,但是高度複雜的最終用戶(技術支持人員)通常可以很好地瞭解問題所在,甚至通過查看高度詳細的錯誤消息來提出新的解決方法。關鍵在於使這些錯誤信息不被模糊地描述,而這更多的是一門藝術而不是一門科學。

來自使用超出proc COM服務器的Windows程序的示例。如果主程序試圖從COM服務器實例化對象和失敗,錯誤消息:

「警告:無法實例 UtilityObject:錯誤‘的CoCreateInstance’‘類不 註冊」’

99%的用戶會看到這一點,並認爲它是用希臘文寫成的。技術支持人員可能會很快意識到他們需要重新註冊COM服務器。開發人員將確切知道哪裏出了問題。

爲了這樣的斷言:一些背景信息,我通常會使用一個簡單的字符串的方法,使得它明確在出現錯誤的名稱,或別的東西聯繫起來在我的C++代碼(我回答的道歉你並沒有問語言):

int someFunction() 
{ 
    static const std::string loc = "someFunction"; 
    : : 
    if(somethingWentWrong) 
    { 
    WarningMessage(loc.c_str(), "Unable to Instantiate UtilityObject: Error 'Class Not 
    Registered' in 'CoCreateInstance); 
    } 
} 

...產生:

警告[someFunction]:無法 實例化UtilityObject:錯誤 '類未註冊' 的 'CoCreateInstance