Updated and adapted for general QOF usage, May 2005 Neil Williams <email@example.com>
I like this for several reasons:
The problem with automatic reconnect from within the backend is that you don't know quite where to restart... or rather, you have trouble getting to the right place to restart.
You can't just re-login, and reissue the commit. You really need to rewind to the begining of the subroutine. How can you do this?
Alternative 1) wrap the routine and retry three times.
Alternative 2) throw an error, let some much higher layer catch it.
Well, approach 1) seems reasonable... until you think about what happens if three retries doesn't cut it: then you have to throw an error anyway, and hope the higher layer deals with it. So even if you implement 1), you *still* have to implement 2) anyway.
So my attitude is to skip doing 1 for now (maybe we can add it later) and just make sure that when we "throw" the error, it really does behave like a throw should behave, and short-cuts its way up to where its caught. The catcher should probably be a few strategic places in the GUI, like wherever a QofQuery() is issued, and wherever an object is edited.
What's the point of doing 2 cleanly? Because I suspect that most network / filesystem errors won't be automatically recoverable. Most likely, either someone tripped over an ethernet cable, or the server crashed or the disc is full and you gotta call the sysadmin on the phone or clear out some files, etc. The goal is not to crash the client when the backend reports an error, but rather let the user continue to work.
We should use the session error mechanism for reporting these errors. Note that the API allows a simple 'try-throw-catch' style error handling in C. Because we don't/can't unwind the stack as a true 'throw' would, we need to make sure that when we "throw" the error, it emulates this as best it can: it short-cuts its way up and out of the engine, to where its caught in the GUI.
If there are a *lot* of places where these calls are issued, simplify things by implementing your own callback mechanism.