> 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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list