Hi,
On Fri, Nov 28, 2003 at 06:12:19PM +0100, Julien BLACHE wrote:
> Here's a proposal for SANE2 regarding error handling.
This answer is not only for Julien, but concerns the whole thread.
Please everyone reread the discussions on the error handling for sane2
in the list archives. Most of this has already been discussed and it's
not that easy unfortunately. I'll comment on some of the proposals only:
> As of now, error
> handling is somewhat imprecise and often not meaningful, and we're
> spending everyone's time debugging problems that could be solved
> quickly if only the user was given the appropriate status/error
> message.
I also propose to add more appropriate/detailed fixed error messages
now. We don't even have "File not found". While this is easy, it's not
that useful (which file hasn't been found?).
> Proposal 1:
> -----------
>
> Define SANE_Status as a struct :
>
> typedef struct {
> int code;
> char *msg;
> } SANE_Status;
>
> SANE_Status.code is *always* a standard SANE status code.
>
> If SANE_Status.msg is NULL, then the standard SANE status message is
> printed, end of the story.
>
> Otherwise, the custom SANE_Status.msg is printed, and the caller must
> free SANE_Status.msg.
First i thought that way may be troublesome with net/saned. But it may
be possible as the struct can be transmitted as any other SANE
structure. The net backend gets the string from saned and allocates
memory on the client. saned frees the memory on the server immediately
after copying the string over the net. The real backend frees the
string taht was allocated by the net backend.
Open questions: translation. Who translates such error messages? The
backend or the frontend?
I don't see any other problems with that proposal currently. i don't
like the "backend frees" approach but that's probably the only one
that works.
> Proposal 2 (preferred) :
> ------------------------
>
> Slightly redefine SANE_Status, as a 32bit integer where the 2 MSB are
> a backend-specific error code and the 2 LSB are a standard SANE status
> code.
>
> The 2 LSB will always correspond to a SANE status.
That's ok.
> If the 2 MSB are non-zero, they are passed to a sane_backend_status()
> routine inside the backend that returns a proper status message that
> is then echoed to the user. (depending on what we want to achieve,
> we'd require the caller to free the message after use, think
> sprintf(), etc...)
That opens a can of worms. Which error message is printed? Remeber
that more than one device can be open at the same time. In case of
threads we are in trouble now. We also can't supply the SANE_Handle
because otherwise we couldn't print errors before sane_open.
If we used that proposal, we would have to disallow threaded
frontends. Or to be more exact: disallow running more that one sane
api function at the same time.
The SANE option containing the error message has the same problem: It
only works once sane_open succeeds and if the error doesn't occur in
sane_control_option.
I think returning the string at the exact time when the sane api
function returns is the only way.
And while defining structs keep in mind that the SANE standard only
defines what a SANE_Word is. There is no "short" SANE_Type and it's
also not defined that four SANE_Bytes are as long as one SANE_Word.
SANE_Word may be 64 or even 128 bits.
Bye,
Henning
