Re: [Libexif-devel] Error handling: proposal

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

Hi Uli & Lutz,

thanks a lot for summarization. Items 1. and 2. are exactly the
reasons for my proposal. Translation of log messages makes the
current situation evem more messy.
To the complexity: I was originally thinking about upto 10 status
codes, now my estimate is 10-15. I don't expect 30+ status codes.
As there are some fatal errors when LibEXIF gives up (fully
or partially - skipped rest of IFD) and some _warnings_ when LibEXIF
more or less continues (e.g. skipped {not fully interpreted} just 1 tag),
I am proposing structuring of the status codes for those who are interest=
ed.
I really want to avoid thread local storage, extra allocation,
stacks or other (complicated) tasks.
We are dealing with many corrupted files and buggy SW around, we need
reasonable error reporting.

 --- Jan

> Lutz M=C3=BCller <lu...@us...> writes:
>
>>>> On Sun, 2005-04-03 at 20:07 +0200, Jan Patera wrote:
>>> I would return the first (or last - must be discussed) error of the
>>> highest severity of all errors/warnings encountered.
>>
>> To summarize, exif-result.h would
>>  - define 30+ error/warning codes (that must be discussed)
>>  - define a hierarchy of those error codes (that must be discussed)
>
> Sounds pretty complex to me.
>
>> I really doubt that programmers will implement checks for that many
>> error codes and get some useful information out of them. gnome-vfs for
>> example has exactly this problem.
>
>
>> Let me propose something different. It is up to the frontends to log
>> messages and handle the queue (like now). Functions would return one
>> or more of the following result codes:
>>
>> EXIF_RESULT_NONE =3D 0,
>> EXIF_RESULT_DEBUG =3D 1 << 0,
>> EXIF_RESULT_WARNING =3D 1 << 1,
>> EXIF_RESULT_ERROR =3D 1 << 2
>>
>> Frontends would do:
>>
>> res =3D exif_data_something ()
>> if (res & EXIF_RESULT_ERROR) {
>>   "Errors have occurred..." (show logged errors)
>>   if (res & EXIF_RESULT_DEBUG) {
>>     "Additional debugging information is available. Click here to show
>> it."
>>   }
>> } else if (res & EXIF_RESULT_WARNING) {
>>   StatusBar =3D "There have been problems executing the request. "
>>               (show logged warnings)
>>               "Click here to show more info."
>    if (res & EXIF_RESULT_DEBUG) {
>      "Additional debugging information is available. Click here to show
> it."
>    }
>> }
>>
>> That is: Only a couple of result codes. Few log codes. No hierarchy.
>>
>> How about that?
>
> Simple to implement in libexif.
>
> Simple to implement in a frontend, if the log functions are memory leak
> and buffer overflow safe.
>
> However, I see a potential problem:
>
> There may be cases when the frontend could react in a "sensible" way to
> certain kinds of errors, if it knew about the nature of the
> problem.
>
> The frontend needs more information in machine readable format, but tha=
t
> should be information relevant to the frontend.
>
> We have to keep in mind what we want to achive:
>
>   1. Frondends must know when a call to a libexif function failed.
>
>   2. The most simple way to transfer the information is its return
>      code, so it would be really nice if the frontend could do a
>      simple =3D=3D 0 or !=3D NULL comparison to find out whether the ca=
ll
> succeeded.
>
>      It is not coincidence that this is the standard way to do error
> reporting in C. :-)
>
>   3. There must be more detailed information for the user - the stuff
>      in the log messages. These are mostly translated, except perhaps
> for the lowest level debug info.
>
> Considering these three points, I'd suggest classic C library/POSIX
> return conventions, but with a slightly improved error reporting
> mechanism than a global "errno" variable (I don't think we want to deal
> with thread local storage).
>
> And the logging already goes a long way towards improvements. Of
> course, functions returning "int" can easily return a large number of
> different error codes, but with NULL pointers... I'm not sure ATM how t=
o
> do something similar here without resorting to a global error
> function... hmm... a callback function perhaps, like the logging?
>
> Uli