Hi, On Sun, Dec 08, 2002 at 01:14:35PM +0000, Diego Zuccato wrote: > Henning Meier-Geinitz wrote: > > > So the backend would call the callback immediatly, when a fatal error > > occurs. Fatal means, that it will return anything other than > > SANE_STATUS_GOOD. This would work for command-line programs but may be > > messy for graphical frontends. > Errr... Since you're defining a new API, then why not return a ptr to > typedef struct { > int errornum; > const char *errmsg; > } SANE_error; > or momething similar ?
And this would be returned by any SANE API function that currently returns SANE_Status? Nice, because it links the error number and the message. No need for an extra call to a function. > This way, the failing function sets both the numerical error code AND > the (verbose) error message. However: How long is errmsg valid? Until the next call to any SANE function? That's bad because the frontend may get in trouble when using threads. Until sane_exit()? Then the memory usage gets bigger and bigger. > You don't like structs? :-) Lots of structs are already in SANE :-) > Then a success might be indicated by a NULL ptr, while an error is a > string like "NNN verbose message follows error code" (like many net > progs already do). > Want numerical error code? atoi(retval) and you get it. Is atoi() too > slow? Then use > #define ERRCODE(rv) (rv?(rv[0]*10+rv[1])*10+rv[2]:0) > So you could even have the same error code for different error messages. > Really useful when debugging a module: the error code tells the failure > type, and the rest of the message helps tracing it down. The pointer > should point to a list of static strings, so it remains valid as long as > it's needed. Well, a list of fixed error messages wouln't be a problem at all. We could jsut add some more detailed error codes to the existing SANE codes. The really interesting error messages are the dynamic ones: "Couldn't open %s". And %s can be anything and can change multiple times between sane_init and sane_exit. Yet another way would be to use an additional callback: void sane_error_message_callback (SANE_String error_msg); Call it in your SANE API function if an error occured that will lead to a return value of anything other than SANE_STATUS_GOOD. error_msg is only valid during the runtime of sane_error_message_callback. The calback only explains the error in more detail, the actual error is flagged by the return value of the SANAPI function. Not too nice, either. If only C would copy strings when returning them as the return value of functions :-) Bye, Henning