5

I'm looking for some sort of standardisation, in a similar vein as POSIX for compatibility and familiarity between different commandline-interfaces, but for error reporting. Notably, I'm looking for:

  • formatting rules
  • standardisation of logging practices
  • rules for error code choice
  • good habits on how much, and what to include in your error report to the user
  • design decisions on providing additional metadata on the state of the software, should the user wish to see it or report it.
  • multi-language support (i18n)

etc...

closed as too broad by Doc Brown, gnat, ChrisF Feb 3 at 18:36

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    You are expecting too much. Even if such a standard exists (never heard of one before), I guess chances are high it will actually not be a good fit to your real-world project (you have one, I hope?) – Doc Brown Feb 1 at 21:38
3

There is no recognized and commonly used standard for that.

I suppose that you ask this question in order to avoid all the mistakes you may do by reinventing the wheel. In order to avoid those mistakes, you may be interested in checking the following:

  • The logging format (and logging tools) of the operating system. The way you log in syslog is not exactly the way you log in Windows Event Log. They are similar, somehow, but they do have influence on how applications log things.

  • The logging framework for the language you use. This alone saves a lot of time in terms of reinventing the wheel by abstracting away all the low-level stuff, including log rotation when logging to files, formatting with a date-time and other common fields, and filtering.

  • Popular projects in your domain. Seeing how, for instance, RabbitMQ logs the messages is more relevant if you're writing a message queue system than if you're engineering a system which controls planes.

  • Projects in your company. Applying the same patterns again and again is important, because it ensures consistency. When a person from another team moves to yours, if projects are consistent all over the company, this person doesn't have to waste time re-learning the logging part. This way, from the first day, he'll be more efficient when debugging problems.

2

You may be able to find such guidelines on a per-industry basis. NATO, NASA may have guidelines (although I don't have concrete examples). Large companies may have some guidelines.

I write embedded code for the medical device industry. I have created my own error reporting format based on Microsoft's HResult, and used it in multiple companies under regulatory control. Nobody have ever mentioned that I should adopt an existing industry standard.

Not the answer you're looking for? Browse other questions tagged or ask your own question.