There are many programmers who really need to be beaten with a clue stick. Error messages are not okay. Sure in the dark ages we had trivial amounts of memory, cpu and disk and every byte mattered. What distinguished the good programmers from the bad was how efficient they were.
But now we have effectively unlimited memory, cpu and disk. Our units of measurement are in the billions. It is also virtually certain that the programmer who writes the code to generate a message knows more about the situation than the user who is going to be receiving the message. So why throw your hands up with some terse mumbo jumbo instead of doing something about it? Feel free to use those billions of units of memory, cpu and disk that are mostly unused at any moment. Good programmers now are ones whose code meets the users' goals. (Hint: approximately zero users have a goal of having to copy a message into Google and then wading through pages of results until an obscure solution appears to work.)
Here is a case study on trying to install a package:
(Reading database ... 90%dpkg: unrecoverable fatal error, aborting: files list file for package `libc6' contains empty filename E: Sub-process /usr/bin/dpkg returned an error code (2) A package failed to install. Trying to recover:
How many users of dpkg went out and created a package with an empty filename? Zero is a good answer. Anyone getting this message is not the cause of the problem so why are they being told. How about ignoring the empty filename? Or how about automatically running a tool that rebuilds whatever database it is, omitting the empty filename that is such a source of grief to the dpkg programmer? Heck there are many good solutions, but none of them involve what happened there.
