1. Why com_err?

In building application software packages, a programmer often has to deal with a number of libraries, each of which can use a different error-reporting mechanism. Sometimes one of two values is returned, indicating simply SUCCESS or FAILURE, with no description of errors encountered. Sometimes it is an index into a table of text strings, where the name of the table used is dependent on the library being used when the error is generated; since each table starts numbering at 0 or 1, additional information as to the source of the error code is needed to determine which table to look at. Sometimes no text messages are supplied at all, and the programmer must supply them at any point at which he may wish to report error conditions. Often, a global variable is assigned some value describing the error, but the programmer has to know in each case whether to look at errno, h_errno, the return value from hes_err(), or whatever other variables or routines are specified. And what happens if something in the procedure of examining or reporting the error changes the same variable?

The package we have developed is an attempt to present a common error-handling mechanism to manipulate the most common form of error code in a fashion that does not have the problems listed above.

A list of up to 256 text messages is supplied to a translator we have written, along with the three- to four-character “name” of the error table. The library using this error table need only call a routine generated from this error-table source to make the table “known” to the com_err library, and any error code the library generates can be converted to the corresponding error message. There is also a default format for error codes accidentally returned before making the table known, which is of the form ‘unknown code foo 32’, where ‘foo’ would be the name of the table.

This document was generated by Build Daemon on February 22, 2015 using texi2html 1.82.