Hi If my memory don't full me (it's many years now since I last used C) then: - the convention is to return 0 for success, some enumeration for failure. - in severe errors you can throw exception (I don't remember exactly how they are called) and catch them at the main program to exit cleanly (close all files, free resources, restore terminal settings ...). you can start learning about this by following the divide by zero error
Hope this helps Shahar ----- Original Message ----- From: "guy keren" <[EMAIL PROTECTED]> To: "Haifa Linux Club" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Friday, February 07, 2003 3:18 PM Subject: [Haifux] OT: PROG question: regarding returning errors in libraries > > hi, > > as part of writing various programming libraries, i keep stumbling on the > issue of returning errors (this includes the issue of a function notifying > its calling funciton that it had an error - and what that error was, in a > way that will allow the calling funciton to both handle the error, and > [optionally] report it to the user. right now, i'm not interested in how > to actually report the error to the user or the programmer). > > the following 'discussion' focuses on programming in C, and is thus > limited to features supported by the C language. > > i am aware of several 'error reporting' models: > > 1. "C"'s errno - there is a global (or a global-per-thread, in multi > threaded environments) variable in which an error code is returned, in > case the function invoked failed. > > all error codes come form one pool of error types - and should be > interpreted by the caller, in the context of the specific function > invoked (i.e. ENOSPC for a semaphore creation is not the same as ENOSPC > for writing into a file). this makes it easy for the programmer to > remember the different error codes (cause they repeat all the time in > all programs). on the other hand - if a function has some specific > errors, adding them to the large pool of error codes seems irrelevant. > > there is a function that translates the error code into a > human-readable string (strerror) - but there is no way to supply an > error-specific error string - this is left for the caller to do. this > is ok when the functions perform little tasks - but is insufficient > when the function does a complex job (e.g. recursively delete a > directory) - and we need to give some context in the errors. > > another advantage of this mechanism is that every "C" programmer is > familiar with it, and thus will learn it easily, if it comes in a > different library. in fact, libraries may even piggy-back on top of > it, and return their own errors inside the global 'errno' variable. > > another problem with this mechanism - the error code must be > checked/stored immediately after the call, since calling another > function might change this global 'errno'. this is especially annoying > (and prone to errors) if we need to make some cleanup if there was > an error (e.g. a function that needs to check the 'magic number' of a > file - it needs to open the file, read the magic number with a 'read' > call. if the 'read' fails, we want to report its errno to the user - > but we need to first close the file - and this close might change the > value of errno - and thus we need to temporarily store errno's value > before the clode, so as not to loose it. > > 2. specific error codes set per function - in this manner, each function > defines its own set of error codes. it should also need to supply its > own error string, since it can no longer be derived by a single global > function. > > this makes the error reporting flexible, and somewhat 'type save' (one > could define an enum for the error codes of a given function in the > library, and then the user can make a 'switch' on the various error > codes, with the compiler warning them if they forgot to check one of > the possible values. > > the problem is this makes the programmer have to remember (or look-up > often) the error codes for different functions. this is especially > annoying when propagating errors back to the caller. > > 3. the function returns the error code by itself (with either a > per-function errors enum, or a global list of error codes - with one > value for 'success'). this puts consistency into the code (every > function that might fail reports an error code) - while making the > interface less convinient, when the funciton could sometimes have > returned a pointer (e.g. the 'fopen' functoin returns a pointer to a > FILE on success, or NULL on failure - and this works because it can > report the error code in the global 'errno' variable). > > there could also be the model of 'only report success or failure - the > error code itself does not matter' - which is valid for certain situations > (e.g when there's nothing to do with the eror, except for freeing the > resource for which it was done and aborting the operation, without > reporting anything else to the user). > > i wonder what people here have to add regarding these models, or regarding > other models (again - for the "C" language) they have used, or wanted to > try to use. > > if you comment - please state if you're talking about somehting you used, > something you've started using lately, or something you didn't yet use. or > if its soemthing you've read about somewhere. and please be fair - i.e. > when you describe your magnificent no-problem error reporting system, > please also state what are the bad parts of it - where it was annoying, > what in it would you improve if you had the time, or if you had an idea > how to do, etc. > > thanks, > -- > guy > > "For world domination - press 1, > or dial 0, and please hold, for the creator." -- nob o. dy > > > -------------------------------------------------------------------------- > Haifa Linux Club Mailing List (http://www.haifux.org) > To unsub send an empty message to [EMAIL PROTECTED] > > -------------------------------------------------------------------------- Haifa Linux Club Mailing List (http://www.haifux.org) To unsub send an empty message to [EMAIL PROTECTED]
