From: Hans U. N. <gp...@n-...> - 2005-04-04 20:33:49
|
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 that 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 call 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 to do something similar here without resorting to a global error function... hmm... a callback function perhaps, like the logging? Uli |