Stephan Bergmann wrote:
On 02/12/10 09:30, Rich wrote:
speaking as a user here, not a coder - if software can continue with
operating, it should. yes, it should warn me, but it should run as
long as possible, either allowing me to save the document, copy data
out of it or whatever.
The irony is, once you have hit a programming error, you can no longer
have confidence in the program's behavior. It could happen that the
data you still manage to save is subtly corrupted, so subtly that you do
not notice immediately. This is indeed a dilemma, and there is no
golden way out. That said, in the event of a crash (which would include
the abort from an assertion in a non-product build) OOo already tries to
save your open documents (and it appears to be somewhat effective at it).
i'd like to point out one thing i've noticed in other projects with
user vs developer mentality. if a user reports program closing, it is
a _crash_ for them. you might call that "assert", "controlled quit" -
it does not matter. at all. to the user, software crashed. and that is
the last thing i want from any software, especially one i rely some of
my most important data ever to.
Sure, nobody wants to suffer the consequences of programming errors.
However, the software industry happens to be in a state where errors are
a frequent reality. The question, then, is how best to carry on once a
programming error has been encountered (if the software has the luxury
at all to even notice).
Fail fast (abort) has the potential to cause the least data loss and the
least confusion (the program does not continue running in an
uncontrolled state, corrupting the user's data or giving wrong answers
to the user).
yes, that i can totally agree to. so we should distinguish two things
here (which you already did in the previous email).
1. a problem, caused by outside data - opening a corrupted document,
image or whatever - should never ever result in closure;
2. a problem "inside" code.
yeah, i understand that often figuring out which one has happened is
hard or impossible, but hey :)
so we're interested in second category only here. still, i'd argue that
software should attempt to let me revive as much of data as possible...
it should not carry on ignoring the error, of course. it should popup
some message, tell me to save my work and restart it. maybe it should
add some "nagging" bar to inform me about it all the time and motivate
to restart it.
what i have encountered in oo.org several times - i'm working on 4 or 5
documents at the same time, let's say 3 text documents and 2
presentations. if suddenly a problem arises in presentation code, i
definitely do not want it to close and lose my changes to the text
documents. i want to be notified and given a chance to check them.
while automatic saving for recovery is useful, it is also not easy
enough to use and efficient :
1. it seems to ignore the fact that i have saved the document and offers
it for restoring as well. that takes more time.
2. after all those files are restored i have to manually check each for
differences from the manually saved versions (it is possible that either
manually saved or automatically saved version is newer). again, this is
cumbersome or near impossible for some types of documents.
3. if one of the input files triggered the failure, oo.org will crash
again upon restoring them. yes, theoretically i can recover them
manually from profile and remove, or i could hit cancel at first and
then save files when prompted (but i am never sure when i will be
offered to save them, and there is no way for user to know that there
will be such a chance - huge usability problem, imho)
while problems with recovery are semi-offtopic, i hope they help to
highlight reasons why i'd prefer a chance to salvage the data myself,
especially when working on many files of different types.
i completely understand the argument about masked failures and data
corruption risks. and i can't agree with them enough :)
i'm not arguing against being in-your-face about such problems - it's
just that i've been burned by such problems with oo.org and other
software before, and lost data (or time :) )
Carry on regardless (ignoring the detection that the program has reached
an uncontrolled state; what effectively happens when assertions are
disabled in production systems) can be considered unacceptable behavior.
It potentially leads to corrupting the user's data or giving wrong
answers to the user, with the user not being aware that those answers
are wrong.
Working around the detected *programming error* is probably the best for
the user, but, as I outlined in my other response, nothing you can
expect to happen in OOo in the near future (probably as unlikely as OOo
not having any program errors to begin with).
a short summary - i'd prefer working around it only for as long as it
would take for me to decide what data i want out and get it. whether
saving, copying text or even taking a screenshot.
-Stephan
--
Rich
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
