[sane-devel] [SANE2 proposal] Error handling

Julien BLACHE jb at jblache.org
Sat Nov 29 16:20:36 GMT 2003


Major A <andras at users.sourceforge.net> wrote:

Hi,

>> typedef struct {
>>   int code;
>>   char *msg;
>> } SANE_Status;
>
> OK, but that char* needs to be allocated and freed, which is always a
> complication.

Sure.

> Also, the entire thing must be network-transparent -- any such
> dramatic change to the standard would require a change in the network
> protocol as well, and a char* just complicates things.

If we're to change the standard, we can change the network protocol
too, and even more if we want a complete, secure rewrite of saned...

>> 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.
>
> Packing information into integers like this is ugly, I'm sure there's
> a better way of doing things.

Maybe, but at least it's still a simple, basic data type, and given
the way SANE status codes are defined, 16 bits are more than enough
for now.

> Here's another proposal: introduce a new standard option called
> something like "last-status". This is a read-only string option, not
> displayed among the normal options, that can be read out at any time,
> and the returned string is simply the verbose form of the status of
> the last function call to the backend. If that option is not defined,
> the backend simply reverts to the SANE_Status way of reporting errors.
>
> This doesn't require SANE2, BTW, it could be added any moment, even to
> SANE1, and would be completely network-transparent.

That's another way, but it looks like a kludge to me as options aren't
designed to report errors :)

JB.

-- 
Julien BLACHE                                   <http://www.jblache.org> 
<jb at jblache.org> 




More information about the sane-devel mailing list