[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[stewart@serissa.com (Lawrence Stewart)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1172 bytes --]

Being too lazy to type __FILE__ and __LINE__ all the time I tend to do this:

#define whereprintf(fmt, ...) printf("%s:%d: " fmt, __FILE__, __LINE__, ##__VA_ARGS__)

which works when fmt is a constant anyway.

My rant about error messages is that programmers too infrequently make them actionable.  

I group errors into 4 categories:

* Things the user can fix (file not found)
* Temporary resource constraints (destination unreachable, disk full)
* Things the admin can fix (library not found)
* Things the author of the program can fix (assertion failures)

In each case, the kind of information needed is different, and the level of noise and specificity may differ as well.  The user wants to know (a) how to fix it or (b) who to ask.

Finally, When faced with an unfamiliar error, the natural reaction of a 2017 user is to cut and past the error into a search engine.  Consequently I think often the right thing to do is to put a unique ID in the error message that will find it on the support website (or user forum, or …)

-L

PS Daughter is working on a master’s project to improve the quality of errors from the python interpreter/compiler.  Sorely needed.