乙個軟體系統，肯定是涉及到很多錯誤資訊。比如使用者執行出錯了，軟體需要將錯誤資訊返回給使用者。那麼如何設計錯誤碼及錯誤資訊呢？錯誤資訊如何返回？下面以乙個簡單的場景來說明。比如現在我們乙個ui模組（介面模組）和乙個algo模組（演算法模組），其呼叫關係如下圖：
在這裡要提及乙個很不好的程式設計習慣，就是在假如在algo模組內部出錯，開發人員往往在algo模組裡彈出錯誤資訊提示框。這種習慣是很不好的，不好在**？在於乙個演算法模組應該儘量減少介面元素的侵入，如果乙個演算法模組帶有介面元素，往往限制了這個介面模組的移植性，比如從乙個介面框架移植到另乙個介面框架，從一種作業系統移植到另一種作業系統。正確的做法是怎麼樣的呢？就是演算法模組應該返回錯誤碼給介面模組，介面模組通過錯誤碼獲取錯誤資訊來彈出錯誤資訊。
如何設計錯誤碼？在這裡我們先考察一下他人的做法，比如windows api。在windowsapi中有不少函式是bool型別的，函式的返回值一般就是返回true表示成功了，返回false表示失敗了。如果使用者需要更詳細的錯誤資訊，需要呼叫乙個getlasterror的函式來獲取錯誤碼，再根據錯誤碼來獲取錯誤資訊。
windows api這種設計好不好呢？在我看來它勉強可以解決問題，但是存在一些弊端。弊端一在於需要使用全域性變數把錯誤碼儲存下來。大家知道，全域性變數是使用越少越好的。弊端二在併發時可能出錯。比如在多個執行緒中同時呼叫同乙個函式，錯誤碼如何區分這幾次呼叫呢？有解決這個問題的辦法，但這個解決辦法又增大了系統的複雜性。
有沒有更好的設計？更好的設計就是函式的返回值不再返回bool型，而是返回int型別。返回的int值表示錯誤碼，介面模組根據錯誤碼來獲取錯誤資訊。這樣的話錯誤碼就僅僅需要是乙個臨時變數了。
當然問題還是有的。比如有多個演算法模組，如何避免它們占用同乙個錯誤碼，比如100？我設想的是有乙個全域性的動態增加錯誤碼起始值的函式，以100位區間。比如a演算法模組的錯誤碼區間為100到200，b演算法模組的錯誤碼區間為201到300。
說完錯誤碼的設計，我們再談談錯誤資訊的設計。錯誤資訊的設計也是有學問的。首先我們需要明確一點，錯誤資訊應該面向什麼人？可能有人笑了，這還用問，錯誤資訊不就是面向軟體使用者的嗎？這個答案對，但是不完整。首先錯誤資訊確實是面向軟體使用者。明白這點我們就該想到好的錯誤資訊不應告訴使用者現狀是什麼，更應提示使用者怎麼解決問題。諸如「資料處理失敗」就不是好的錯誤資訊，因為這僅僅是告訴了使用者現狀是什麼，如改為「資料處理失敗，原因是***輸入引數輸入不正確」更好，因為它揭示了解決辦法，使用者看到了明白了是因為輸入了錯誤的***引數而導致處理失敗的。下次他操作時就會注意輸入這個引數了。錯誤資訊除了面向使用者，還應面向誰？還應面向開發者。因為出錯後使用者只能把自己的操作情況及看到的錯誤資訊告訴技術支援人員，而技術支援人員最終把錯誤資訊反饋給開發者。因此錯誤資訊詳細一點不是壞事，使用者看不懂問題不大，開發者卻可以憑藉這個資訊來幫助使用者解決問題。
java使用列舉封裝錯誤碼及錯誤資訊
使用列舉型別來封裝project中所需要的錯誤碼和錯誤資訊，十分方便。用法如下 package com.dear.r.dbservice author lixiang 使用列舉型別來封裝異常碼和異常資訊 public enum dbserviceerror public string getmsg ...
錯誤資訊的處理
1 採用前台驗證為主，後台驗證為輔的驗證流程 前台主要驗證與資料庫無關的資訊，如是否數字 是否超過最大輸入範圍 有無輸入必輸項 後台主要是驗證與資料庫有關的資訊，如是否有同名等 這裡面用的技術主要是提交form採用 color red validatorform color public class...
tuxedo 錯誤號及錯誤資訊描述 tperrno
近幾天在檢視tuxedo服務端返回客戶端資訊發現了許多tperrno 在這裡我把tuxedo errno 對應的資訊描述出來。tperrno 1 tpeabort transaction cannot commit tperrno 2 tpebaddesc bad communication des...