錯誤代碼和消息最佳實踐

Question

我正在計劃一個EDI系統，它發送包含多個元素的XML確認消息，但具體包括這三個; ErrorCode，ErrorSeverity和ErrorDescription。

我將基本上解析入站XML消息，並根據解析的成功或失敗，包括消息格式，語法，結構，有效性和一些業務規則，我將返回成功或失敗確認。

我有免費的統治選擇ErrorCodes，ErrorSeverity和ErrorDescription，而不是天真地開始在ErrorCode [1]，ErrorSeverity [錯誤]，ErrorDescription [無法找到入站XML文件]並添加錯誤，因爲我認爲他們在編碼的入站消息解析器我想知道是否有挑選錯誤代碼和嚴重性的最佳做法？

我知道HTTP錯誤代碼就像OK消息的2xx，某些錯誤的4xx，服務器錯誤的5xx等，並想知道如果任何人有任何好的建議，可能會幫助我的道路之前，我編碼自己到角落和說：「如果只有我所有的」警告「錯誤開始與3或類似的東西！

我認爲ErrorSeverity不會超過[錯誤]，[警告]，[信息]和[確定]也許

感謝

Answer 1

你可以找到現有的錯誤碼爲EDI這裏：。

http://msdn.microsoft.com/en-us/library/bb245948.aspx

如果您使用其中一個文檔中描述的標準之一，您將與之通信的系統/開發人員可能會很高興。

Answer 2

我喜歡將「錯誤」（輸入數據錯誤）與「致命」（系統損壞）區分開來。第一個要求修復數據並重試;另一個沒有。

不言而喻，任何「錯誤」消息應該是可操作的;他們應該向接收方明確哪些問題是錯誤的，以及需要採取什麼行動來糾正數據中的錯誤。

如果您單獨通報嚴重程度，那麼我不僅看不到任何需要堅持預定義的數字範圍，我建議這樣的舉動是一件直白的事。如果您做決定有使用範圍助記符值，使至少十次大範圍比你認爲你現在需要（數字很便宜，爲什麼不能用五年？;-)

您還可以考慮您的參數化消息;例如顯式字段以指示文本中的位置。這使得代碼更容易接收消息並做一些有用的事情（而不必解析查找線索的人類可讀文本）。