Re: turning g_assert* into warnings

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

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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]