Re: GtkBuilder report

[Emmanuele Bassi <ebassi gmail com>]

hi Brian;

On Tue, 2007-01-23 at 11:03 -0800, Brian J. Tarricone wrote:
 
> > Not really a blocker IMO.
> > It's easier to add error handling code when you find broken glade files or
> > are adopting an existing program to output something GtkBuilder can parse.
> > libglade does well here, so we should definitely improve this at some point.
> 
> IMO, this is *definitely* a blocker.  assert()/abort() statements have
> no place in a shared library[1].

you arrive a little late: GLib and GTK+ already use assertion failures
to check for the internal state of the library.

>   As an application developer --
> especially a _GUI_ application developer -- I expect that the libraries
> I use will not terminate my application, ever.  If something Very
> Bad[tm] happens inside the library (even if it's my fault), I want to be
> able to inform the user via a popup dialog box and then quit my
> application gracefully.

and how do you propose to gracefully recover from the absence of the
whole user interface definition?  if such a thing happens in production
if means you've screwed up the installation of the application so badly
that you can't really trust anything to be working correctly - hence an
abort() is the Right Thing(tm) to do; if this happens during a
development cycle, then you'll be monitoring the standard error anyway,
so whether gracefully presented to you or not, you're going to notice
the error.

> The *only* time I will accept assert()s in a library is the unlikely
> scenario where there really is no way to recover, and continuing along
> with any kind of error-handling attempt presents a real risk of data
> loss (or some other catastrophic thing).

and, pray tell, why the failure to find the definition of the whole UI
of you application does not fall into this category?  remember:
GtkBuilder can be used to define the tree/list stores for your tree view
too - I'd say that not being able to get those objects is a pretty bad
scenario, which might lead to data loss.

ciao,
 Emmanuele.

-- 
Emmanuele Bassi,  E: ebassi gmail com
W: http://www.emmanuelebassi.net
B: http://log.emmanuelebassi.net