On 2/12/10 11:02 AM, 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).
Pardon me, but you are confusing me. If as you say we should crash ASAP
because an assertion may have subtly corrupted your data, then
consequently we shouldn't save the documents either.
That may be the puristic vantage point, but crashing and loosing the
user's work with 100% probability instead of saving it with 99.5%
probability seems a bad idea to me. Because if you're honest, those
"subtle ways the document may have changed erroneously" are really
really rare compared to the number of assertions hit.
Sure, nobody wants to suffer the consequences of programming errors.
However, the software industry happens to be in a state where errors are
make that the universe, you may have noticed that errors are not a pure
software thing ;-)
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).
On the contrary, "fail fast" = abort, is the only way to make 100% sure
that the user's work is lost.
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.
Yes, shit occasionally happens. But with the same reasoning we should
abandon all traffic, because there have been accidents.
Simply crashing *on purpose* is IMHO not a solution. Give the user the
choice to continue at least. If warning boxes pop up all over the place,
the point of users filing issues is also achieved but at the same time
gives the user the opportunity to save his work.
Just my 2 cents, pl
--
Sanity is just a bad excuse for a lack of imagination.
-- Author unknown
Registered Office: Sun Microsystems GmbH, Sonnenallee 1, D-85551
Kirchheim-Heimstetten
Commercial register of the Local Court of Munich: HRB 161028
Managing Directors: Thomas Schröder, Wolfgang Engels
Chairman of the Supervisory Board: Martin Häring
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
