Re: turning g_assert* into warnings

[Tim Janik <timj imendio com>]

On Fri, 12 Oct 2007, Mathias Hasselmann wrote:

> Am Freitag, den 12.10.2007, 11:52 +0200 schrieb Tim Janik:
> > note that in practice, this shouldn't change anything for programmers
> > (except for the ability to write better code ;)
> > because of G_DISABLE_ASSERT, programmers can already not rely on
> > failing assertions to abort their programs (only g_error will reliably
> > do that).
>
> I was in strict "HELL, NO!" mode until I read this reasoning. Still I am
> not sure if G_DISABLE_ASSERT is a misfeature, since when using g_assert*
> instead of g_return* or g_warning you usually really have no good
> fallback strategy and therefore accept the program crashing.
>
> So for better error handling I'd suggest keeping the old and boring "if
> (blub) { g_warning ... } paradigm.

> So I guess what you really want is some kind of "g_soft_assert" or some
> "g_warn_if_fail".

thanks for the input, however i'm not surprised you bring this up ;)
i thought about suggesting some g_assert_warn() myself before i proposed
changing g_assert.
i didn't suggest introducing that because i fail to see a considerable
benefit in introducing it over adapting g_assert.

it boils down to these two properties of g_assert:
a) g_assert issues a warning about failing assertions, so in this regard
   it already achieves what we'd otherwise use g_warn_if_fail() for;
b) we already can't rely on g_assert abort()-ing a program, depending on
   the build time flag G_DISABLE_ASSERT.

given (b) in particular, g_assert already provides no stronger guarantees
than g_warn_if_fail would, so i think it'd be most straight forward if
we adopted the code to be more consistent about (b) so we only abort for
--g-fatal-warnings, and be more explicit (in the docs) about the existing
need that you have to use g_error() to reliably abort.

to some extend, this could be seen as just enabling a runtime switch
(--g-fatal-warnings) for an existing build time option (G_DISABLE_ASSERT).

> Also remember that such a dramatic that (external) programmers most
> certainly  do not expect their program to continue after a failed
> assertion (despite  the G_DISABLE_ASSERT misfeature). So not calling
> abort on failed assertions could make the program eat little children,
> if not worse.

the same reasoning applies to g_return_if_fail(), so i'll extend on it
here for a bit.

for development phase i welcome all available aid for developers and
support early catching + fixing of program errors, often done best with
gdb + --g-fatal-warnings (after all, that's why this option was introduced
in the first place).

for end-users however (i.e. production phase), it simply turned out that
warn + return for our many function call guards is much friendlier.
contrary to a developer, a user can't fix the program if it aborts, and
contrary to a developer, the user can loose critical data due to an
unneccesarily forced abort. (if developers trust critical data to their
programs during development phase, that's their own responsibility ;)

i'm not proposing any change in semantics here, glib/gtk+ programs
that spew a critical, warning or error are by definition in an undefined
state. the cause of which must be fixed, and no support or guarantees
for program behavior after a warning can be made.

however, the above end-user friendly reasoning about g_return_if_fail
also applies to g_assert, so i think assertions should be adapted to
act accordingly (abort on --g-fatal-warnings and not otherwise like
g_return_if_fail).

> Ciao,
> Mathias

---
ciaoTJ