The Part 2 ended with the summary: In a good error reporting system, the errors should have both the types/codes for the automatic handling and the free-form human-readable strings with the detailed description. However there is one more way, a sort of "middle" way, that is used by the Event Tracing for Windows (ETW).
The idea there is that a message contains not just a simple string but an error code that allows to find the formatting string in a manifest plus the data to be used in the formatting string. The actual conversion to a string happens at the last stage, when the user wants to read the message. Then the information about the message type gets looked up by its code, the formatting string and the format of arguments get extracted from there, and the formatting gets applied.
That has the advantages:
- The messages in the binary format are short and efficient. Since the ETW messages seem to be born out of the profiling tools, that probably was important.
- The localization is applied at the last stage, so everything gets translated to the end user's language, even if the message was generated on a system with another locale.
- The automated tools that process the error logs don't need to parse the message text (which is particularly difficult if the messages may be in different languages), they get the data values directly in the binary format.
The catch is that to do all that, the reader must have access to the manifest that describes the meaning and formatting of the messages. Moreover, to the exact same (or at least s future backwards-compatible) version of the manifest as used by the producer of the messages. Which is OK for the messages being processed on the same computer in real time but much more difficult after the messages have been copied to another computer for processing, or even if the messages have simply been stored for some time. So it's really not the best approach for the massive collection and long-term storage. Without the manifest, the messages are just an unreadable jumble of bits.
And of course the files with the ETW messages are the binary files, and need tools for reading them. PowerShell provides a bunch of commands like Get-WinEvent that help a bit.
And there is also the pain of writing the manifests in XML.
And there is no provision for linking the ETW messages together, as was discussed in Part 1.