Hi Frank,
Frank Schönheit - Sun Microsystems Germany wrote:
Hi Kay,
Propagating errors is the broader concept, comparing assertions and
error propagation. So, if in doubt, propagate! Never swallow unclear
situations (especially _not_ in _production_ code, following effects may
destroy valuable data), upper levels may know what to do or at least can
wan the user.
This is a nice theory, but one which doesn't fit the reality of 6
So, at least you like the theory?!
millions of line of code grown over the last 15 years.
I thought we have about 10 million lines?!
If from tomorrow onwards we would propagate every error which today is
"handled" with an assertion only, then in reality OOo would crash every
few minutes, since nobody else will handle it, either. (Take a
non-product build of m125 and try it out.)
We do *not* have a consistent error concept in place, and as much as
this is regrettable, it's also a fact which we cannot change by starting
with "error propagation" in some isolated places.
Interesting, this is a change in attitude. Before, you said (at least
that is how I understood it, please correct me if I am wrong), that the
way how we are currently using assertions etc. is the _correct_ way.
Now, you are saying, that the reason we are using assertions the way we
are using them is historically founded. In other words, implementing the
above theory would be right, if doable at all.
But the reverse is also not true, a runtime failure might be caused by a
bug. Nevertheless you want to propagate this failure, to give someone
the chance to react and to correct.
Exactly this "someone" is what I don't believe in. In reality, there
will be nobody.
Some systems support some sort of transactionality. This is the someone
needed. Good error handling has IMO to go hand in hand with
transactionality.
If I have the choice between the application crashing (or at least being
non-functional, which today for instance is the result of an access
violation on Windows, e.g. dereferncing a NULL pointer), and between
reacting as if the user didn't do anything, then I choose the latter. We
have zillions of crash reports, and in my opinion [1] there's hardly
something worse than a crash, from a user experience point of view.
I think we had this before. A user loosing data because an application
overwriting his files with nonsense, will _never_ send a crash report.
OSL_VERIFY is just a convenience syntax for OSL_ASSERT and I don't agree
that it is abused more often or more prone to abuse than OSL_ASSERT. So
I don't see a reason to discard OSL_VERIFY, without also discarding
OSL_ASSERT.
Just some (selected :-) examples:
case PROPERTY_ID_REFVALUE :
147 OSL_VERIFY( _rValue >>= m_sReferenceValue );
148 calcValueExchangeType();
149 break;
Bad example, I claim this is no abuse here (since you disagree, please
try to convince me).
Yep, stupid example. Sorry. Didn't think that the operator is overwritten.
It is my believe (and you know, about beliefs is no easy argumentation
;-), that real situations for utilizing assertions in the classical (and
IMHO this is the only) sense, are rare. Most errors / unexpected
conditions should be propagated and be handled (see above).
I have the feeling we should care for a "well-balanced" attendees when
having our "assertions/diagnostics" meeting. We should have somebody who
is used to work on 15-year-old Writer code, not only people whose oldest
code is younger than UNO itself ;-)
Certainly. Feel free to invite somebody. My last comment was intended to
more or less terminate the thread, which mmmhhh did not work ;-). I am
certainly open for arguments and willing to change my mind if the
arguments are convincing.
To do this, we probably would need some sort of schema / concept.
And this is the difficult part, IMO: Having a consistent error handling
concept which is *applied across the whole application*. I'm in for
pragmatism here, even if this means not always following the "pure
doctrine" ...
Ever seen the "general I/O error" box when trying to save a document?
Without any clue what was going wrong? And already thinking about how to
best copy the (textual) content into the next emacs window?
We sooner or later should solve this.
Ciao
Frank
Kay
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
