> C. It looks interesting to have global error codes in error messages > (such as "GLIBC0003: File not found").
Error numbers are disgusting, meaningless, and I hate them. A better idea: *** Just print the name of the actual function or method in which the error occurred. *** This is something I do in one of my own programs (It's called "Madeline", so the command-line prompt is an "M"): M> xyz GetToken(): "XYZ" is not a recognized token M> open "xyz" SmartTableSelect(): Can't open "xyz" for reading. Perhaps the path or file name is incorrect. M> graph "xyz" Graph(): Unrecognized GRAPH command. M> There are a lot of things I like about doing it this way. First, it helps me as the programmer. Secondly, things change over time. For example, The OPEN command shown above in the past called a function called Open(), but then I added a more intelligent wrapper that detects different file types and so now the OPEN command actually calls SmartTableSelect() which eventually calls Open() or does something else, depending on the situation. If a user were to report a problem to me, the fact that "SmartTableSelect()" is being shown tells me right away which version number they must be running. Also, because of reporting error messages this way, I don't have to use gdb to trace through a hierarchy of function calls very often: Usually the error message tells me right away where to start looking. The error message alone, such as 'Can't open "xyz" for reading' could have been generated by any number of commands since the program opens up lots of different files at different times. So having the actual function name reported saves a lot of time. Also, I don't present the user with some useless and annoying error number as if I were writing a program for Windows 95 ... Remember, the *Nix philosophy is to assume that the user is intelligent and knows what he or she is doing. So let's present the user with intelligent and useful information, not useless error codes! - Ed Trager Bioinformatics Kellogg Eye Center University of Michigan Ann Arbor, USA > -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
