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.
In general, you shouldn't be writing to stdout at all from your library - even in a console application that could corrupt the output that the application is producing. stderr is a little more forgivable, but you still shouldn't really use that unless the application requests it.
The OpenSSL is a cross-platform shared library that had much the same problem to solve. Their method has the library record detailed error information in an internal error queue, which the application can request when an error return value is seen and then present to the user in whichever way is appropriate. (It also provides a convenience function that dumps the entire error queue to a FILE *).
For log messages, you should allow the client to supply a callback function to the library so then the client can decide what to do with them e.g. send to syslog or display in a window on the screen.
For returning errors, you have three basic strategies:
- return an error code and have a function that translates it into a message
- pass a pointer parameter that points to an object that will hold error message information
- Have some global library object that contains error information from the last operation.
Whatever you do, you don't want to just log the error message because the client might want to do something with it. e.g. present a dialog box.
I'd probably go with 2 mostly.
On linux, instead of printing the error on standard output (or standard error), you should log the error using rsyslog. Since you are dealing with GUI, maybe you can also pop a message box (not always).
I have no idea about the windows, but I think it has something similar.
