On Fri, 2011-05-27 at 17:09 -0400, Havoc Pennington wrote: > Hi, > > Man, how many times has this thread happened? At least fifty. > > On Fri, May 27, 2011 at 10:57 AM, Shaun McCance <sha...@gnome.org> wrote: > > try: > > load_some_extension() > > except: > > warn("This extension sucks. I'm disabling it and moving on.") > > > > Of course, GLib is C. We don't have exceptions. We have GError, > > which is a decent foundation for exceptions in language bindings. > > But if we don't use it, then languages that could otherwise do > > the right thing are screwed. > > This is the core thing. People who expect no g_error/abort are used to > languages with exceptions. > > The thing that's different about C is that an "exception" (think > GError) changes the function signature of that function... _and_ *all > callers* in any library or app!
I really don't want to carry this thread much further. It is getting bike-sheddy. We disagree. I'm not the one making the decisions. Life goes on. But I want to point out that my point was never that GLib should behave like a language with exceptions. Just that it should let bindings in those languages behave like they should. What I would do (take it or leave it, and let's move on with our lives) is make the constructor return NULL if there's a problem and make all consumers of GSettings abort if passed NULL. Same effect, just perhaps delayed. I don't think it risks any more data loss than the current behavior. The advantage is that bindings could do a NULL check and raise an exception. With introspection-based bindings, this kind of NULL-check-and-raise can even be done automatically, perhaps with a flag like raise-on-null. -- Shaun _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list