Hi,
Kay Ramme - Sun Germany - Hamburg wrote:
Joerg Barfurth wrote:
It is the very purpose of OSL_VERIFY to evaluate the expression
regardless of debug level. For expressions without side effect
OSL_ASSERT/OSL_ENSURE should be used instead.
It is used to avoid cluttering the code with extraneous temporary
variables and control structures for assertions about values that are
not used otherwise.
Return values signaling the success or failure of a function call are
typically ideal candidates to be promoted further, up the call stack.
I agree. If they signal runtime conditions that prevent normal
operations, they can be converted to exceptions, otherwise they should
be dealt with or propagated as approriate. (I think in most cases where
errors are propagated repeatedly up the call stack an exception would be
better, though).
Assertions are not intended to be used for runtime conditions. They
document and cast in executable code invariant assumptions or conditions
that must hold every time the code is executed[*].
There are cases where it is valid to ignore the return value of a
function - whether it is a success/failure code or some other data -
because the expected value is known in advance and is (or should be)
independent of runtime conditions.
For example you don't have to check whether a 'sqrt' function fails, if
you have made sure that the argument you pass is a positive number. Or
you don't have to check that inserting something into a map succeeds, if
you know that you have a unique key for the new entry.
[*] There may be other uses for debugging macros, but for assertions
that is the defined meaning. But the following reasoning also holds for
other legitimate uses of assertion macros.
Only in very very rare situations this has to be "asserted".
I don't think these situations are that rare. And they are definitely
distinct from the cases where error propagation is in order. An
assertion that triggers is always a bug. That is not true for an
arbitrary runtime failure in some module.
So, such an OSL_VERFIY, which only logs something in case of
OSL_DEBUG_LEVEL > 0, really _displaces_ error detection and handling!!
OSL_VERIFY shouldn't log, but assert (i.e. check) a condition. It is
true that our code has places where proper error handling is displaced
by (abuse of) assertions. It is also true that this is Evil(TM).
But I don't think this abuse should be used against the vaild uses of
assertions. They are a powerful helper during development and
maintenance. 'Always-on' assertions could also be used to diagnose bugs
that occur on customer sites.
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.
Unless you think that all assertions should be replaced by fully
propagated runtime checks, I see no argument to get rid of OSL_VERIFY.
Ciao, Jörg
--
Joerg Barfurth Sun Microsystems - Desktop - Hamburg
>>>>>>>>>>>>>>>>>> using std::disclaimer <<<<<<<<<<<<<<<<<<<<<<<
Software Engineer [EMAIL PROTECTED]
OpenOffice.org Configuration http://util.openoffice.org
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
