Joerg,
Joerg Barfurth wrote:
Hi,
Kay Ramme - Sun Germany - Hamburg wrote:
Joerg Barfurth wrote:
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).
Exceptions or error values are semantically the same.
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[*].
Certainly agreed as elsewhere. Assertions not holding true are _fatal_,
in this sense.
There are cases where it is valid to ignore the return value of a
Certainly true, not needed return values as e.g. indexes or such can be
ignored.
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.
Disagreed. Runtime dependent success/failure codes _must_ always be
propagated. Such errors may be the result of bugs or other unknown side
effects or changed implementation details and are typically non fatal.
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
IMO not true. I can _not_ ensure all parameters to be valid in all
circumstances to all function calls beforehand, especially without
knowing implementation details. Exactly this, dealing with invalid
parameters in the broader sense is the reason for error handling in general.
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.
IMO wrong. There might be bugs, unknown side effects, out-of-memory
conditions or other things happening, which are not under your control.
Still, the right thing is to notify somebody (the user, upper levels)
that something went wrong!
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.
[*] 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
We probably need to do some analysis, to clarify this finally :-)
distinct from the cases where error propagation is in order. An
Agreed.
assertion that triggers is always a bug. That is not true for an
Agreed.
arbitrary runtime failure in some module.
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.
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).
Yep.
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.
I am all for assertions, if used correctly (and this is probably again,
what we are discussing :-).
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;
150
151 case PROPERTY_ID_UNCHECKED_REFVALUE:
152 OSL_ENSURE( m_bSupportSecondRefValue,
"OReferenceValueComponent::setFastPropertyValue_NoBroadcast: not this
supported!" );
153 OSL_VERIFY( _rValue >>= m_sNoCheckReferenceValue );
154 break;
155
156 case PROPERTY_ID_DEFAULTCHECKED :
157 OSL_VERIFY( _rValue >>= m_nDefaultChecked );
158 resetNoBroadcast();
159 break;
160
Unless you think that all assertions should be replaced by fully
propagated runtime checks, I see no argument to get rid of OSL_VERIFY.
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).
To do this, we probably would need some sort of schema / concept. And I
have to admit, after doing the threading stuff, I am not really keen on
working on this :-). So, please take my apologies for having brought
this up again.
Ciao, Jörg
Kay
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
