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 millions of line of code grown over the last 15 years. 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. > 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. 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. >> 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). This is from an implementation of setFastPropertyValue_noBroadcast of an ::cppu::OPropertySetHelper derivee. The contract of this method is that it gets passed values which it beforehand obtained from the convertFastPropertyValue implementation. So, if the implementation is consistent, this assertion will never fire. IOW, you cannot make this assertion fire by just using the public API of the class, only by changing the classes implementation inconsistently. If, however, the implementation *is* inconsistently changed (by convertFastPropertyValue not providing a string anymore), this will most likely be found immediately while developing it, long before a release. What would be the alternatives? Not using OSL_VERIFY at all, but throwing? Chances are good that some clients exist which will not catch it, so I prefer behaving as if the call did not happen (which is the case since m_sReference value is not changed). Ignoring the error completely? Then I would not even notice the inconsistency during development. So, an OSL_VERIFY is the best handling one can do here, IMO. Similar argueing holds for your other examples. > 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 ;-) > 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" ... Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Database http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
