错误代码和消息最佳实践

时间:2009-02-18 12:31:34

标签: error-handling edi error-code custom-errors

我正在计划一个EDI系统,除其他外,它发送一个包含多个元素的XML确认消息,但特别是这三个元素; ErrorCode,ErrorSeverity和ErrorDescription。

我基本上将解析入站XML消息,并且根据解析的成功或失败,包括消息格式,语法,结构,有效性和一些业务规则,我将返回成功或失败确认。

我可以自由选择ErrorCodes,ErrorSeverity和ErrorDescription,但不是天真地从ErrorCode [1]开始,ErrorSeverity [错误],ErrorDescription [无法找到入站XML文件]并添加错误,因为我在编码时会想到它们入站邮件解析器我想知道是否有选择错误代码和严重性的最佳做法?

我知道HTTP错误代码对于OK消息是2xx,对于某些错误是4xx,对于服务器错误是5xx等等,并且想知道是否有人有任何好的建议可以帮助我在我将自己编码到一个角落并说“如果我的所有”警告“错误都是以3或类似的东西开始的话!

我认为ErrorSeverity不会比[错误],[警告],[信息]和[确定]更多吗?

感谢。

2 个答案:

答案 0 :(得分:2)

您可以在此处找到EDI的现有错误代码:

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

如果您使用其中一个文档中描述的标准之一,您将与之通信的系统/开发人员可能会很高兴。

答案 1 :(得分:1)

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

不言而喻,任何“错误”消息都应可操作;他们应该清楚地告知收件人究竟出了什么问题以及需要采取什么行动来纠正数据中的错误。

如果你是分别传达严重性,那么我不仅没有看到任何需要坚持预定义的数字范围,我建议这样的举动是直接夹克。如果你决定使用范围的助记符值,那么使范围至少比你现在需要的大十倍(数字便宜,为什么不使用五个?; - )

您也可以考虑参数化您的消息;例如显式字段以指示文本中的位置。这使得代码更容易接收消息并使用它做一些有用的事情(无需解析人类可读的文本寻找线索)。