Re: g_assert() semantics is changed without announce

[Stefan Kost <ensonic hora-obscura de>]

Tim Janik schrieb:
> On Fri, 26 Sep 2008, Andrew Cowie wrote:
> 
>> On Thu, 2008-09-25 at 13:06 -0400, Matthias Clasen 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
>>
>> In the Java bindings we trap the log messages that are raised by
>> assertions and propagate a (quite fatal) Java Exception instead. That
>> quite nicely terminates the program, but in a way that a) gives the
>> developer some idea of where things are wrong, and b) doesn't crash the
>> VM in the process. Crashing VMs are rather frowned upon.
>>
>> The fact that assert uses the existing log facility is lovely. Please
>> revert back to this!
> 
> Thanks for the feedback and use case descriptions everyone, I can
> definitely
> see the point why people want to see g_assert() using g_log() be restored.
> 
> Similar reasons do apply in the testing framework case though, e.g.
> assertion
> messages from test programs should be sent on to the gtester framework
> executavle for logging and should usually not pollute stderr.
> 
> I'll investigate if we either:
> - Restore g_assert()s old logging behaviour unless g_test_init()
>   has been called; or
> - Restore g_assert()s old logging behaviour unconditionally and just
>   capture + redirect everything from g_log() to gtester after
>   g_test_init() has been called.
> 
> I hope that should fix everyone's issues.
> 
> ---
> ciaoTJ

I think the second is the best option.

Ciao
  Stefan