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

[Linas Vepstas]

On Tue, Jul 17, 2001 at 02:22:28PM -0400, James LewisMoss was heard to remark:
> >>>>> On Tue, 17 Jul 2001 13:09:42 -0500, linas@linas.org (Linas Vepstas) said:
> 
>  Linas> (I've been planning on
>  Linas> making a few enhancements to the backend error reporting
>  Linas> subsystem, to remove some crud and add some features, so if
>  Linas> anyone has requests, now is a good time to bring them up ...)
> 
> What cruft and what features?  I've been working on this code recently
> turning the file backend into a true backend and have made changes in
> many places at this point.

Excellent!

> I was planning on (well already written, but not plugged in yet)
> writing an EngineError/EngineErrorQueue set of objects to hold
> errors.  At the moment the queue is just a GList with some convience
> functions and the Error is an int code and a char *message (should be
> easy to add other things later if needed).


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

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

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

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

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

--linas

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

-- 
Linas Vepstas -- linas@gnumatic.com -- http://www.gnumatic.com/