我想知道錯誤消息的一般共識是什麼。他們應該有多詳細？錯誤消息的詳細程度應該如何？
我工作過的項目有一個不同的錯誤信息，用於輸入一個數字太大，太小，有小數，是一個字符串等等。這對用戶來說非常好，因爲他們確切地知道哪裏出了問題，但錯誤處理代碼開始與實際的業務邏輯相媲美，並開始開發一些自己的錯誤。
在另一邊，我在一個項目中，你會得到非常通用的錯誤工作，如
編譯時失敗，原因3
這不用說是因爲幾乎完全無用原因3竟然意味着鏈接錯誤。
那麼中間的地方在哪裏？我如何知道我是否添加了描述性足夠的錯誤消息？我如何知道用戶是否能夠了解他們出錯的地方？
對於錯誤消息，用戶和開發人員，有兩種可能的目標受衆。
一般應該有消息目標用戶。
o問題的原因是什麼。
o爲什麼程序無法解決問題
o用戶可以如何解決問題。
o如何報告問題。
如果要報告問題，報告應包含儘可能多的程序上下文信息。
O模塊名稱
O功能名稱
O線號的問題
Ø甚至核心轉儲一般地區的利益
O變量。
針對正確的觀衆。
您應該儘可能少地說出所發生的事情以及用戶的選擇。錯誤信息越長，用戶讀取它的可能性就越小。同樣的道理，短的錯誤信息是神祕而無用的。在長度方面有一個甜蜜點，每種情況都不一樣。
太短：
無效的輸入。
太長：
請輸入格式正確的IP地址，例如爲192.168.0.1。 IP地址是用於在網絡上識別您的計算機的號碼。
恰到好處：
請輸入一個有效的IP地址。
就代碼膨脹而言，如果一些額外的代碼會阻止用戶調用支持或變得沮喪，那麼這是一個很好的投資。
「恰到好處」可能太少了。我期望有關用戶輸入內容的信息，以及他應該輸入的內容。例如「不明白'192,168,02'，請輸入一個有效的IP地址（例如192.168.0.2）。」 – 2012-05-02 11:34:06
我會在更詳細的方面犯錯，但我認爲你回答了你自己的問題。爲了避免代碼中的膨脹，請在代碼/錯誤消息中提供有用的信息，但是您可以在文檔中或者在幫助文件或FAQ中提供更多詳細信息。
信息太少在我看來更糟糕。
如果您使用的是具有豐富內省或其他功能的語言，那麼在檢查失敗的情況下執行日誌會很有用。然後用戶可以轉發技術支持或以其他方式獲取詳細信息，這不是額外的代碼膨脹，而是使用您自己的代碼提供信息。
有兩種類型的錯誤消息：那些將被用戶看到的和那些將被程序員看到的。
「我怎麼知道用戶是否能夠理解他們出錯的地方？」 我假設這些消息只會被用戶看到，而不是非常技術性的，並且COMPILE FAILED REASON 3不是典型的最終用戶錯誤消息。這是程序員會看到的東西（用戶通常不會編譯東西）。
所以，如果它的用戶是會看到它：
最後，爲用戶提供一些簡單易懂的命令（「重試」，「取消」等）
這個神祕的錯誤消息的產品是一個編譯器，所以在這種情況下，是的，他們將編譯的東西。但點好了。 – ReaperUnreal 2008-12-31 16:27:56
真正的問題有關錯誤信息，如果他們甚至應該顯示。很多錯誤消息都會呈現給用戶，但他們沒有辦法糾正它們。
只要有一種方法來糾正錯誤，然後給用戶足夠的信息，讓他們自己糾正它。如果他們無法自行糾正，是否有理由告訴他們墜機的技術原因？不，只是將它們記錄到文件中以便稍後進行故障排除
儘可能詳細，他們需要;）
我知道這聽起來像一個聰明的驢子的答案，但這麼多的這取決於你的目標受衆和錯誤的類型。對於由無效的用戶輸入引起的錯誤，您可以向他們展示構成有效條目的內容。對於用戶無法控制的錯誤，通用的「我們正在處理它」類型的消息可能會發生。
我同意Jon B對長度的評論。
錯誤消息應該詳細，但清晰。這可以通過組合來自多個級別的錯誤消息來實現：
Failed to save the image
Permission denied: /foo.jpg
這裏我們有兩個級別。可以有更多。首先我們告訴大局，然後告訴細節。順序是這樣的，首先我們有一部分被大多數人理解，然後這個部分人少了解，但兩者仍然可見。
此外，可能有一個修復建議。
「如何報告問題」 - 或者更好，保證問題已經在此報告 – 2008-12-31 16:43:11
+1。你不想提供不必要的點擊。我無法想象許多用戶會爲此感到不安。 – Jonta 2009-01-23 13:50:27