Re: About gsettings aborting on unkown schemas

[Morten Welinder <mortenw gnome org>]

> The core principle that allows most functions to "always succeed" is
> that programming bugs are not "thrown," they just terminate the
> program.

Havoc, the data doesn't agree with that assertion.
Let's look at numbers:

glib, number of not-crashing on programmer errors:
# find glib -type f -name '*.c' -print | xargs -n100 grep -E
'g_return_(val_)?if_fail' | wc -l
1509

glib, number of crashing on programmer errors:
# find glib '(' -type f -name '*.c' -print ')' -o '(' -type d -name
tests -prune ')' | xargs -n100 grep -w -E 'g_assert|g_error' | wc -l
213

gtk+, number of not-crashing on programmer errors:
# find gtk '(' -type f -name '*.c' -print ')' -o '(' -type d -name
tests -prune ')' | xargs -n100 grep -w -E 'g_return_(val_)?if_fail' |
wc -l
5637

gtk+, number of crashing on programmer errors:
# find gtk '(' -type f -name '*.c' -print ')' -o '(' -type d -name
tests -prune ')' | xargs -n100 grep -w -E 'g_assert|g_error' | wc -l
693

So the overwhelming conclusion is that glib and gtk+ handle programmer
errors by issuing a "critical" and returning. Not by crashing.

It tips even more in that direction when you realize that a good
fraction of the crashing calls do not actually catch (library user)
programmer errors, but problems more in the memory-corruption
department.

We know that not having the schema around is not good.  Going postal
and killing the program is not the solution.

Doing a g_return_val_if_fail is fine here.  That will give the user a
chance of saving his work.  This is in contrast to g_error which is a
sure way of eating data.

Morten