Re: [Libexif-devel] Error handling

[Jan P. <pa...@pi...>]

Hi Lutz,

should I understand it as you are strictly against completion codes
returned by exif functions?
With the current code, many error situations are not propagated.
(see also for example bug #1169213). Ambigious completion codes should
be commented like in the header file "part of tags may have been
successfully parsed. It is upto you (i.e. the programmer) if you discard
everything or use partial results of what has been parsed."
I am not calling for changed program logic. I am just proposing that
instead
if (! is_this_correct(x)) {
 exif_log(blabla);
 return;
}
the code should be like

if (! is_this_correct(x)) {
 exif_log(blabla);
 return EXIF_STATUS_X_IS_WRONG;
}

It is up the user of the library (I again mean the programmer)
if he decides to parse log are use the error codes.
As a programmer, I _much_ more prefer the error codes.
Which doesn't mean I don't like displaying the log messages.
I just want offer the user (or do automatically) just only the appropriat=
e
actions when something goes as not expected.

 -- Jan

> On Wed, 2005-03-30 at 11:25 +0200, Jan Patera wrote:
>> Lutz occasionally adds calls of exif_log() when something goes wrong.
>> Various error conditions can be determined by constants
>> like EXIF_LOG_CODE_CORRUPT_DATA.
>> The bad thing is that exif_log() is then followed by return;
>> because most functions return void.
>
> I wouldn't call this a bad thing. libexif has processed the request as
> far as possible (even when having encountered non-critical problems lik=
e
> unknown markers and so on). Everything (including errors) has been
> communicated to the frontend.
>
>> I believe it would be
>> much better if the functions returned some completion status, like 0
>> for success and non-zero values like EXIF_LOG_CODE_CORRUPT_DATA when
>> something goes wrong.
>
> It certainly would make programming much easier in some cases. But what
> do in case of multiple errors (like 2 unknown tags and 1 bad format but
> otherwise data ok)? I'd rather let frontends scan the log messages for
> errors. If there are categories missing (AGAINST_SPEC,
> NOT_ENOUGH_DATA...) we can just add them.
>
>> Besides corrupted data, it is currently nearly impossible e.g.
>> to see why no libexif data was obtained - it can be missing libExif
>> APP marker, no rights to the JPEG file or even suddently missing JPEG
>> file.
>
> libexif is about reading EXIF data. Handling above problems is not in
> the scope of libexif (IMHO). In my opinion, exif_data_new_from_file is
> just a quick&dirty convenience function. It works in most cases, but
> you'd better:
> exif_data_new_mm
> exif_data_log
> exif_data_load_data
>
>> The only way how to see what went wrong is actually kind of
>> asynchronous interception of results of exif_log invocations
>> and analysis of the results later
>
> Which is not so bad. That way, you've got all information instead of
> just a code.
> --
> Lutz M=FCller <lu...@us...>