I just helped someone whose Fedora Core 3 installation was producing the following error message:

# yum check-update
Setting up repositories
Cannot find a valid baseurl for repo: updates-released

This is a beautiful example of a Unix tendency that people gripe about: technically correct but completely useless error messages. While yum is correctly complaining that it cannot generate a valid URL for the 'updates-released' RPM repository, it would be much more useful if it told us why, with an error message such as:

Cannot fetch mirror list: unable to resolve hostname 'fedora.redhat.com'

This would have immediately led us to wonder why the machine could not resolve the name, which in turn would have led us straight to the actual problem, a broken /etc/resolv.conf.

Generating useful and accurate error messages is an art, and that means that you should think about it when writing programs. Especially think about how propagating useful errors back to the top level will impact your program's structure, because it often does. This especially applies when writing system programs, which are the ones that are often going to break in mysterious ways and leave people very worried and lost about.

Python makes it pretty easy to do a variant on this, where at each step of handling an error you prepend your packet of context information and then pass it upwards. The end result winds up with errors that look like this:

Cannot find a valid baseurl for repo updates-released: while getting mirror list: cannot fetch URL http://download.redhat.com/<blah>: Hostname not found.

This is long but at least complete, and lets you know what went wrong at the lowest level and all of the steps backwards to the high level failure. (Python programs often use simple strings as the error messages, but there is no reason why a GUI program cannot put more structure in and thereby display a more concise dialog. Possibly with an 'expand for the gory intermediate details' option.)