Re: [Libexif-devel] Error handling

[Lutz <lu...@us...>]

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.=20
> The bad thing is that exif_log() is then followed by return;
> because most functions return void.=20

I wouldn't call this a bad thing. libexif has processed the request as
far as possible (even when having encountered non-critical problems like
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.=20
--=20
Lutz M=FCller <lu...@us...>