I am writing a cross platform shared library (.so in linux and .dll in windows) using C. Currently when there is a error, library functions returns the proper error code and writes error information into the stderr. Library functions also emits some information and debug messages to stdout. This works well for console based clients.
Now this library will have client programs that uses GUI programmed using C++ & wxWidgets. I am wondering what would be the best practices in handling the errors and notifying it? Can a UI application access data coming to stdout and stderr on all platforms?
An alternative way I was thinking is the library initialization function initializes a structure which will have function pointers. All the functions on the library will take an instance of this structure and call the function pointers. This way the client can choose where to print the messages.
I am wondering what would be the obvious way to solve this? Any help would be great.
Best practice (IMHO) is for a library to not print anything to stderr (or stdout), because they may not even be present. In addition to the GUI situation, you also have the use case of a server application that doesn’t have a “console”, and may want to be logging errors using a function like syslog().
Some approaches for handling error information without printing it directly:
return a numeric error code, and provide a function for turning it into a string
return a struct/object error code, which contains additional information
provide a function on a “session” object that returns info about the last error
allow the caller to register a callback that’s invoked in the event of an error
The one exception to the “don’t write to stderr from a library” rule that I’m reasonably comfortable with is if a library has a “debug mode” parameter that enables logging of detailed info to stderr.