gEDA-dev: libgeda error reporting

[Igor2]

On Tue, 3 Jul 2007, Ales Hvezda wrote:

>[snip]
>>Ales, I assume you were talking about this type of logging when
>>you said I shouldn't remove all logging calls. But I really think
>>the behaviour here should be just setting the error string and
>>returning NULL. In my opinion, either the library uses stdout/stderr
>>(or log file, doesn't matter) or it doesn't. So far I think it's 
>>pretty clear that I prefer the latter option. 
>
>
>	Okay.  If you are going to set out on this huge task, please
>keep in mind that for every error condition and log msg that you remove
>from libgeda, you must handle it eventually in the top most layer.
>You may find this somehwat awkward as you will have to pass the error
>strings/msg up several layers.  You may also find that getting that
>error msg/code up from a function is tricky since most functions already
>return a value and you will have to resort to the same sort of mechanism
>as GError suggests.  
>

We had a similar problem in libgpmi. Calls return error code if something
goes wrong so that the caller can dislay an error message if it
wants. However, sometimes the caller would like to give details
(i.e. "File not found" vs. "something.so not found"). The next problem was
what if the caller is libgpmi itself (recursive calls). The caller could
extract only the upmost layer's error message ("Could not load
library: something.so", but no reason given).

The method we are currently using is per thread error stack. Each entry in
the stack has an ID that tells which gpmi call generated the entry and a
textual message. If the caller doesn't want to report errors, it can
simply ignore the whole error stack and just exit/assert/panic when a lib
call fails. If it wants detailed error reporting, after a call returned
error status, it can call a library function which prints the
stack. Printing is not done using printf or fprintf or any other hardwired
call, but the caller provides a callback function which is called for each
error stack entry. 

This way when GPMI fails to load a module, the caller can display an error
message that tells that something.so was loaded, it's dependency foo.so
was loaded and an unresolved symbol xy was found in it.

The drawback of this method: if you don't flush the error stack often, it
may grow big, especially if you store not only critical errors but
warnings or even infos in it.

Igor2