StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PODesign considerations for an error logging/notification library in C
text
Body
copied!<p>I'm working on several programs right now, and have become frustrated over some of the haphazard ways I'm debugging my programs and logging errors. As such, I've decided to take a couple days to write an error library that I can use across all of my programs. I do most of my development in Windows, making extensive use of the Windows API, but the key here is flexibility: this library ideally needs to remain flexible, offering the programmer notification options in console apps and GUI apps on Windows and Unix-like environments.</p> <p>My initial idea is to use one library that uses preprocessor conditional inclusion of the headers for windows and unix based on the current environment. For example, in a win32 app, console error message notification (while possible) isn't necessary; instead, a simple</p> <pre><code>MessageBoxA/W(hWndParent, TEXT("Some error message that makes sense in context"), TEXT("Application Name"), MB_ICONERROR | MB_OK) </code></pre> <p>would make the most sense. On the other hand, on linux things are a little more complex:</p> <pre><code>GtkWindow *w; w = gtk_message_dialog_new(pOwner, GTK_DIALOG_MODAL, GTK_MESSAGE_ERROR, GTK_BUTTONS_OK, TEXT("Some error message"); gtk_window_set_title(w, TEXT("Application Name")); </code></pre> <p>On either operation, simple file logging with more information about the error (function, file, line, etc.) would also be useful in pinpointing the source and tracing the flow.</p> <p>Moreover, logging should be possible: even when a function requiring error logging/notification is called, it should be possible to show the sequence of function calls in the program, if that level of logging is activated.</p> <p>Thus, my initial considerations are to have a library that incorporates all of these features, with minimal overhead by dint of preprocessor conditionals. I think it would make the most sense to break this up into a couple structs:</p> <ul> <li>The "main" struct, which is passed to every function in the main program requiring logging, and contains <ul> <li>A bitmask containing the status codes for which file logging is necessary (e.g., NOERROR | WARNING | CRITICALERROR or CRITICALERROR | CRASH)</li> <li>A pointer to an "output" struct</li> <li>A linked list of "error information" nodes</li> </ul></li> <li>The "output" struct, which handles printing to file, displaying message boxes, and printing to the console</li> <li>The "error information" struct, which contains information about the error (function, file, line, message, type, etc.)</li> </ul> <p>This is just my initial thoughts about this library. Can any of you think of any more information that I should include? Another major issue for me is atomicity of error addition: it's likely that another thread might create the error than the one logging the error, so I need to make sure that creating and adding an error node is actually an atomic operation. Thus, mutexes would likely be the way I'd go about synchronization.</p> <p>Thanks for the help!</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload