Fri 24 Aug 2007 03:14:10 PM UTC, comment #4:
> > Usually software should be written so that data files cannot cause
> > it to crash.
> To talk about that, we need to define "data file" and "crash". The
> glade files can be considered `code' which happens to be written in
> XML instead of C.
Yes, this is true.
Usually, program libraries and shared objects have a versioning scheme
to make it difficult to mis-match incompatible versions. I don't know
whether there is a corresponding scheme for .glade files. If there
is, I hope that we can use it, at least to the extent that each PSPP
official release has a unique version.
> Similary, is an assertion failure a `crash' or an
> error message followed by exit?
It's a crash. IMO, assertions should only be used for conditions that
cannot happen unless there is a bug in the application. The PSPP
handler for assertion failure even explicitly tells the user that
there is a bug and that we would like to hear about it.
That's the way I feel about "assert", anyhow. GTK+ seems to have a
litany of assertion-like constructs with different properties. I've
never looked at those, so I don't really know how I feel about them.
> If an out-of-date glade file, doesn't provide an essential widget, or
> the set of properties that the code expects, then there is no way the
> code could handle this (in the genreal case). The only sensible thing
> it can do is give up. The question is, when should it decide to give
> up? and what error message(s) should it produce?
Giving up quickly, if the error cannot be recovered from, is just
fine. A message like "PSPP file '....' is missing or out-of-date.
Please run "make install"." would be perfect IMO, but I think that
your message "could not find glad file '....'." is fine too.
|