"Tony Lewis" <[EMAIL PROTECTED]> writes: > Steven M. Schweda wrote: > >> Having the exit codes defined in a central location would make it easy >> to adapt them as needed. Having to search the code for every instance >> of "return 1" or "exit(2)" would make it too complicated. > > It seems to me that the easiest way to deal with exit codes is to have a > single function to set the exit code. For example: > > setexitcode(WGET_EXIT_SUCCESS); > or > setexitcode(WGET_EXIT_QUOTA_EXCEEDED); > > This function should be called any time there is an event that might > influence the exit code and the function can then decide what exit > code should be used based on all calls made prior to the end of > program execution. Not only will such an approach restrict the logic > for setting the error code to one place in the code, it will make > OS-specific versions of the error code (such as what Steven desires > for VMS) much easier to implement.
That's not a bad idea at all. Very unconventional (at least to my knowledge), but not bad at all. It could even be modified to accomodate people who want different error codes for different occasions. What Wget could do is: * If no errors have been set, return 0. * If only one error has been set, return an error code indicating which error it was (and document error codes in the manual). * If multiple different errors have been set, choose the last one, which can be expected to have aborted the downloads. After all, many errors are recoverable. * If at least one error has been set and success has also been reported, return a generic error meaning "there have been some errors". That's the best we can do, given that the download wasn't really aborted by the error. This should work both for people who download one URL and expect to get status codes that shed some light on what happened and for people who start a large download and expect different error codes for "OK", "some download failed", and "download aborted". But I wonder if that's overengineering at work.
