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