[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] GNUmed top level exception handler - language advice
From: |
Karsten Hilbert |
Subject: |
Re: [Gnumed-devel] GNUmed top level exception handler - language advice needed |
Date: |
Fri, 11 May 2007 21:33:34 +0200 |
User-agent: |
Mutt/1.5.13 (2006-08-11) |
On Fri, May 11, 2007 at 07:47:06AM -0700, Jim Busser wrote:
> Sorry for the afterthought but even if the user clicks "Close
> GNUmed", may there already have been a problem of their data not
> having gotten, or getting, properly committed?
Getting, indeed, yes.
> I am guessing that even GNUmed *could* (normally) detect and report a
> problem with saving data, this could be impeded by an exception.
Surely so.
> Do we therefore think it advisable that, after an exception, the user
> verified whether their last entry had been properly saved? If not
> with every exception, then with the unhandled ones?
That is certainly so, that's why there's the "try to keep
running" option. Handled exceptions shouldn't pose a problem
- they are handled, after all.
> If so, then maybe after "don't count on it." add one of
>
> Either way, it is advisable to notice if your next (or last) entry
> appears intact.
>
> or
>
> If you keep running, it is advisable to watch if your current entry
> appears intact.
We need to be clear about one thing: When this dialog pops
up something out of the ordinary *has already* happened - an
error occurred which we never knew might happen. The
possible range of resulting events ranges from negligible to
absolutely catastrophic.
The internal state of the application is indeterminate after
this sort of exception occurred.
The "Keep running" button is really only useful in two
cases: You have intimate knowledge of the GNUmed code and
know for certain that the exception is harmless. Or you want
to have a change to *try* to save as-yet unsaved data which
may or may not work, even.
The only way to get back to a (supposedly) clean state of
affairs is a client restart. So, if anything, we might want
to convey this notion even more urgent than we do now.
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346