Error Codes and Messages Best Practise

Question

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.

Answer 1

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.

Answer 2

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).