错误代码和消息最佳实践

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

我喜欢将“错误”（输入数据错误）与“致命”（系统损坏）区分开来。第一个要求修复数据并重试;另一个没有。

不言而喻，任何“错误”消息应该是可操作的;他们应该向接收方明确哪些问题是错误的，以及需要采取什么行动来纠正数据中的错误。

如果您单独通报严重程度，那么我不仅看不到任何需要坚持预定义的数字范围，我建议这样的举动是一件直白的事。如果您做决定有使用范围助记符值，使至少十次大范围比你认为你现在需要（数字很便宜，为什么不能用五年？;-)

您还可以考虑您的参数化消息;例如显式字段以指示文本中的位置。这使得代码更容易接收消息并做一些有用的事情（而不必解析查找线索的人类可读文本）。