Getting the message from the kernel
Posted Jun 22, 2007 18:17 UTC (Fri) by giraffedata
In reply to: Getting the message from the kernel
Parent article: Getting the message from the kernel
Except rare cases the message itself can't give you all this information and we certainly don't want novels to be issued as messages curing this inherent deficiency.
The right length of a message is somewhere between the traditional length and a novel. And it's the same length as developers would write in the "documentation" comment or database or whatever under the message ID proposals. The message manual will not have a novel -- it will contain a few sentences. And they will be fairly inaccurate.
The article talks about the long history of message IDs, but fails to put it in its historical context. Those first message manuals went with systems where storage (including disk space) was so precious you couldn't afford to put a text description of an error in it. The actual error messages had less than 12 characters of text, so they also had a message ID, which was an address in cheap tertiary storage: the paper manual.
Technology has progressed to where it is now a waste of resources to have a person look up a message. It's more efficient to have the computer just tell you what's wrong. But we've stuck with the tradition of terse error messages. They're usually one sentence or less, and in the Unix world, 3-4 words is considered ideal. Only part of this can be explained by programmer laziness; the rest must be just custom.
Other benefits of message IDs have been given here: enabling translation and searching problem databases. But enabling error messages to remain coy and withhold the majority of the information from you isn't one.
to post comments)