Re: GtkBuilder report

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

Emmanuele Bassi wrote:
> 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.

Then I'd consider that a bug.

Though, grepping through glib's sources, it seems that most of them are
related to catching programming errors: i.e., maybe it's better to
abort() there and be able to get a useful backtrace to figure out the
source of the problem rather than just crash randomly later and have no
idea where to look.  Those are areas where providing error feedback
isn't feasible; I'm not expecting every single glib function to provide
a GError to report bugs in glib itself.  So I guess I'd consider that to
be sorta OK.

However, if there are any assert() statements in a path where external
data is being validated -- which is what we're talking about with
GtkBuilder -- that's definitely a bug.

>> 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?

1.  Display a GUI error message to the user (probably most common).
2.  Send an email somewhere reporting the error.
3.  Write something useful to a log file.
4.  Run a fallback or helper program that might allow the user to
accomplish their task another way.

That's just after about 10 seconds of thinking; I'm sure I (or others)
could come up with more.  How is "making the application window
disappear without warning and giving no information" a good user experience?

> 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

No, it's not at all; that's laziness.  The Right Thing[tm] to do is
provide an error through the library's API and allow the application
programmer to do something with it.  If the app programmer decides to do
nothing with it, at least it's his/her choice to be lazy.

> if this happens during a
> development cycle, then you'll be monitoring the standard error anyway,

This is clearly not the case I care about.

> so whether gracefully presented to you or not, you're going to notice
> the error.

As Tristan also mentioned for this specific case in another email, an
abort() in the GtkBuilder parser is ridiculously useless to the
developer: if there's an error in one spot in a several-hundred/thousand
line file, what's needed is information as to where in the file the
error is.  Sure, you'll notice it, but GtkBuilder's poor error-reporting
API design makes it that much harder to track down the actual problem.

>> 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?

I don't define "recover" as "continue on and be able to do your work as
if nothing bad happened."  Of course that's not always possible.  I
define "recover" as "provide a graceful path (which may or may not
include exiting to the application) after giving a useful error message
to the user."  That's by definition impossible when abort()ing.

Who are you or I to say you know exactly why and how people will use
GtkBuilder X years down the road?  Maybe a failure to parse a UI
definition isn't fatal to some applications; it might just make some
features unavailable.  Maybe an app developer won't want to use
GtkBuilder for the entire interface, but just for particular portions
where typing out the raw gtk would be very tedious.  Why should the use
cases of GtkBuilder be artificially limited due to what appears to me to
be nothing more than design laziness?

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

Right, and I'd expect an error in the definition for a particular UI
control to _report an error_.  Not to mention that I'd also expect said
error to also not actually create the UI control that has the error.
Again: let the application developer decide what to do with the error;
please don't assume you know better for every use case.

	-brian