Re: g_assert vs. g_return_if_fail

[LRN <lrn1986 gmail com>]

On 21.01.2010 3:14, Martin Kalbfuß wrote:
> OK, Many thanks. That's a good reason not to use g_assert, in such a
> place.
>
> But when the caller should have the ability to handle the error, why not
> use GError? Isn't it exactly doing this? Indicate an error, but don't
> abort the program on it's own?
>   
GError is for internal errors (errors that may or may not happen, i.e.
I/O, or something that is beyond library's control, such as ACL).
One of the things that Windows does wrong is that it uses the same
mechanism (GetLastError()) for BOTH system errors (such as I/O failing)
and programming errors (wrong arguments). It will often return the same
error, "arguments are wrong", and it's up to you to guess which
arguments are wrong. With g_return_if_fail() you don't have to guess.
Besides, i've seen a few cases when g_return_if_fail() actually returns
and a message is logged, but application continues to function (because
the function that failed was not critical, or there was code to handle
afailure). From user's point of view, that's MUCH better than crashing.
Also, when you're working with GObject, you may come across scripting
languages repeatedly using your functions in strange ways. Crashing on
them is certainly a bad idea.
> Wrong input from a user is not a programming error.
>   
Programming error is the lack of checking of the user input which is, by
definition, unreliable (same could be said about data that came from the
network).