错误代码和消息最佳实践
我正在规划一个 EDI 系统，除其他外，该系统还发送包含多个元素的 XML 确认消息，但具体来说这三个元素； 错误代码、错误严重性和错误描述。
我基本上将解析入站 XML 消息，并根据解析的成功或失败（包括消息格式、语法、结构、有效性和一些业务规则），我将返回成功或失败确认。
我可以自由选择 ErrorCodes、ErrorSeverity 和 ErrorDescription，但不是天真地从 ErrorCode [1]、ErrorSeverity [Error]、ErrorDescription [Cannot Find Inbound XML File] 开始，然后在入站消息编码期间添加我想到的错误我想知道是否有选择错误代码和严重性的最佳实践？
我知道 HTTP 错误代码类似于 2xx 表示正常消息，4xx 表示某些错误，5xx 表示服务器错误等，并且想知道是否有人有任何好的建议可以帮助我在我将自己编码到角落并说“如果只有我所有的“警告”错误都以 3 或类似的数字开头！
我认为 ErrorSeverity 不会比 [Error]、[Warning]、[Info] 和 [OK] 多很多，谢谢
。
I am planning out an EDI system that sends, amongst other things, an XML acknowledgement message containing several elements, but specifically these three; ErrorCode, ErrorSeverity and ErrorDescription.
I will basically be parsing an inbound XML message and depending upon success or failure of parsing to include message formatting, syntax, structure, validity and some business rules I will return either a success or failure acknowledgement.
I have free reign to pick ErrorCodes, ErrorSeverity and ErrorDescription but instead of naively starting at ErrorCode [1], ErrorSeverity [Error], ErrorDescription [Cannot Find Inbound XML File] and adding errors as I think of them during the coding of the inbound message parser I was wondering if there's a best practise for picking error codes and severities?
I know HTTP error codes are like 2xx for OK messages, 4xx for certain errors, 5xx for server errors, etc and wondered if anyone has any good suggestions that might help me down the road before I code myself into a corner and say "if only all my "warning" errors had started with a 3 or something similar!
I think ErrorSeverity isn't going to be much more than [Error], [Warning], [Info] and [OK] maybe?
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您可以在此处找到 EDI 的现有错误代码：
http://msdn.microsoft .com/en-us/library/bb245948.aspx
如果您使用这些文档之一中描述的标准之一，您将与之通信的系统/开发人员可能会很高兴。
You can find existing error-codes for EDI here:
http://msdn.microsoft.com/en-us/library/bb245948.aspx
The systems/developers you will be communicating with will probably be happy if you use one of the standard described in one of those documents.
我喜欢区分“错误”（输入数据有错误）和“致命”（系统损坏）。 第一个要求修复数据并重试； 另一个则不然。
不言而喻，任何“错误”消息都应该可操作； 他们应该向接收者明确说明错误所在以及需要采取哪些措施来纠正数据中的错误。
如果您单独传达严重性，那么我不仅认为没有必要坚持预先定义的数字范围，而且我建议这样的举动是严格的。 如果您确实认为使用范围具有助记价值，请使范围至少比您认为现在需要的大十倍（数字很便宜，为什么不使用五个？;-）
您也可以考虑参数化您的消息； 例如，显式字段指示文本中的位置。 这使得代码更容易接收消息并用它做一些有用的事情（无需解析人类可读的文本来寻找线索）。
I like to distinguish "Error" (the input data were faulty) from "Fatal" (the system is broken). The first calls for fixing the data and retrying; the other does not.
It should go without saying that any "error" messages should be actionable; they should make it clear to the recipient exactly what is wrong and what action needs to be taken to correct the fault in the data.
If you are separately communicating severity, then not only do I not see any need to stick to pre-defined numeric ranges, I suggest that such a move is a straight-jacket. If you do decide there's mnemonic value in using ranges, make the ranges at least ten times larger than you think you need now (digits are cheap, why not use five? ;-)
You might also consider parameterizing your messages; e.g. explicit fields to indicate position in the text. That makes it easier for code to receive the message and do something useful with it (without having to parse the human-readable text looking for clues).