EMZETT.Error Message
In short: A message that a system returns when a problem has occurred, in order to name its cause — in a networking context, e.g. an ICMP message such as Destination Unreachable.
In more detail: Good error messages are specific enough to speed up troubleshooting, instead of just outputting a generic “an error occurred”. Network protocols deliberately standardise error messages (fixed type numbers/status codes) so that they can be evaluated by machines and interpreted consistently across vendor/system boundaries.
In Depth
The three basic requirements
Good error messages typically meet three requirements: they name WHAT went wrong (not just a generic “an error occurred”), WHERE in the system the problem occurred (which component, which processing step), and ideally also WHY or what to do next to fix the problem. Network protocols deliberately implement this with fixed, documented codes instead of freely worded text — every ICMP error message has a fixed type and subcode number (see Destination Unreachable), every HTTP error a three-digit status code (404 = not found, 500 = internal server error, etc.), every SMTP error a three-digit numeric code following a similar pattern. The advantage over pure free text: program code can react reliably to a fixed error number without having to parse and interpret a text message in some language (which can also change between software versions).
Structure of status codes
Many protocols additionally group their codes into meaningful categories, so that even an unknown, specific code can be roughly classified: in HTTP, client errors start with “4” (the requester did something wrong, e.g. 404 Not Found), server errors with “5” (the problem lies with the server itself, e.g. 500 Internal Server Error), success with “2” (200 OK). This rough categorisation makes it possible to recognise the basic error class immediately even for a previously unknown status code, without having to know the exact meaning of every single code by heart.
Human-readable vs. machine-readable error messages
There’s an important difference between error messages intended primarily for people (detailed, explanatory, often with a concrete recommendation — “Please check your internet connection and try again”) and those intended primarily for other systems (compact, standardised, strictly machine-readable, without any ambiguity). In troubleshooting you usually encounter the second kind first (a bare status code, an ICMP type, an error number in a log), and only on closer inspection — in more detailed logs, with analysis tools such as Wireshark, or in an interface prepared for end users — the more detailed variant worded so people can understand it. Good systems consistently translate between the two internally: an internal error code is logged and used for debugging, while the end user is shown a friendlier, generally understandable message that still refers indirectly to the internal code (e.g. via a visible error ID that support staff can then look up in the log).
Pitfall: overly generic error messages
A common design mistake in your own software is swallowing or over-generalising error information — e.g. a catch block that outputs every possible error across the board as “An error has occurred” without recording the actual, original cause anywhere (at least in the log). This makes later troubleshooting considerably harder, because the more precise information that actually existed is irretrievably lost.
See also: Message, ICMP types, Destination Unreachable, Troubleshooting