Hi, On Thu, Sep 25, 2008 at 1:06 PM, Matthias Clasen <[EMAIL PROTECTED]> wrote: > The important part of the assert semantics are: if the assertion > fails, the program aborts. > > If you are using assertions in a way that make it important where or > how the message is reported, I suggest that you are using it wrong...
I leave assertions enabled in my code (they aren't --disable-checks) so I get a decent message instead of a segfault. The usual reason to replace g_log is that you have some canonical place you want to dump a record of what your app is doing / did. The text of an assertion failure is a natural thing to have there. Using assertions in unit tests is a new innovation and *not* the historical purpose of them, since there wasn't even a unit test framework. It is totally legitimate to leave assertions in production code and want them in your app log facility. Now, in real life, most apps end up having to somehow get stderr in their logs anyway, because not everything uses GLib. But, g_log does let you do things in a nicer way, e.g. printing a prefix on the messages, while stderr does not. And the fact that we're hacking around non-GLib stuff doesn't really mean we should require hacking around GLib itself to get everything in the logs. The ideal rule imo: glib should not write to stderr in a non-redirectable way, inside an app. In clearly test-only code, stderr could be fine. But apps should be able to send all output (including - especially including - bugs) to a log file or other custom location. Basically setting a default log handler should kill off stderr, period, for glib-based libraries. Havoc _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list