[sane-devel] SANE V2

[Henning Meier-Geinitz]

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