Re: GtkBuilder report

["Brian J. Tarricone" <bjt23 cornell edu>]

Johan Dahlin wrote:
> Tristan Van Berkom wrote:
>>   - Parse errors should be reported nicely; currently if your glade file
>>     is malformed - you'll get some assertion failure like "assertion
>>     object_info != NULL failed".
>>
>>     Some work has been done already to improve this - by looking at the
>>     error_missing_attribute() function in gtkbuilderparser.c - looks
>>     like these assertions can at least be replaced with some more
>>     informative output.
> 
> 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].  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.

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).

>>   - abort()ing on bad glade files
>>
>>     In my opinion, we shouldnt abort just because a glade file was
>>     malformed (we dont abort on corrupt jpegs afaik) - so what is 
>>     the alternative ?
>>
>>     How about printing an error message about the parse failure/reason
>>     and then destroying the hierarchy that was "created thus far" ? 
> 
> Isn't GError prefered?

This is exactly what I'd like to see: a GError propagated all the way up
to the application.

	-brian

[1] I still cringe a bit over how glib's memory routines abort() on OOM
conditions.  Fortunately (or unfortunately, depending on your point of
view), Linux in its default configuration will never return NULL from
malloc() (of course this says nothing of other platforms where glib is
supported).   OOM conditions on a desktop are pretty rare anyway, I
would think.