Bug: File version number [was Re: SOLVED: 1.7 & 1.6.1-2 cannot co-exist?]

James LewisMoss jimdres@mindspring.com
17 Jul 2001 15:22:00 -0400


>>>>> On Tue, 17 Jul 2001 13:52:43 -0500, linas@linas.org (Linas Vepstas) said:

 Linas> Well, I was thinking of an error "FIFO", but then after a
 Linas> while, I realized that the only error that is really
 Linas> significant is the first error, since the cascade of
 Linas> subsequent ones are just weird side-effects of the first.  I
 Linas> thought FIFO (i.e. queue), not LIFO (i.e. stack) because you
 Linas> want to have the GUI show the first error first, not last.  At
 Linas> any rate, I am no longer convinced that a fifo is needed, as
 Linas> long as we don't clobber the first error to occur before we've
 Linas> shown it to the user.

Possibly only one error at a time is needed.  I've thought about it
and haven't decided one way or another and providing a list of them is
easy so that was the direction I went.

 Linas> Next: error strings. Note that we need *two* distinct erorr
 Linas> string things: first, the type of strings in FileDialog.c that
 Linas> are immediately relevent to gnucash.  Second, I need some
 Linas> "auxilliary" strings that a backend could return.  If there's
 Linas> an aux string, then the GUI should display that.

Agreed.  That's why I was adding the string to the error return so
that extra info can be returned.  And the int code is something the
GUI looks at and determines the GUI specific string (putting the
strings where they should be in the GUI not in the engine).

 Linas> The reason I need this is kind of dirty: Postgres doesn't
 Linas> return error codes, it returns strings.  The strings change
 Linas> from version to version (and are presumably i18n'ed).  So I
 Linas> can't just strcmp them in the postgres backend to figure out
 Linas> what really happened.  I figured that these should just be
 Linas> passed back to the GUI, unmolested, displayed to the user, and
 Linas> let the user try to figure out what to do.

Bleh, but seems reasonable.

 Linas> Cruft: there is convoluted logic in gnc-book.c and in
 Linas> FileDialog.c relating to error handling.  Although convoluted,
 Linas> it is curently doing the 'right thing', so I'm nervous about
 Linas> changing it; its delicate.  But ideally, there 'must be an
 Linas> easier way'.

That's one thing I'm working on.  I've got extensive changes to
gnc-book.c at this point.

 Linas> Part of the problem is that there are three types of backend
 Linas> errors: those that higher layers can deal with automatically
 Linas> (e.g. file-not-found, so look elsewehere in file-path, or,
 Linas> worse, postgres-commit-failed-so-rollback-
 Linas> automatically-but-inform-user-with-popup-anyway), those that
 Linas> require user intervention ('are you sure you want to do this'
 Linas> errors, or 'postgres-
 Linas> you-need-to-give-me-a-password-to-proceed' errors), and fatal
 Linas> errors.  The logic for dealing with the first two tends to be
 Linas> complicated.

This is a problem I think I'll punt on for the moment.  So far
everything seems ok.  Something to revisit later I'm sure.

Jim

-- 
@James LewisMoss <dres@debian.org>      |  Blessed Be!
@    http://jimdres.home.mindspring.com |  Linux is kewl!
@"Argue for your limitations and sure enough, they're yours." Bach