Hi Philipp,
Philipp Lohmann - Sun Germany wrote:
I definately think that
OSL_VERIFY( callSomeFooWhichSignalsSuccess( bar ) );
is the better (non-weird) alternative here.
That case is weird, because you choose to ignore the return value. In
that you create a possibly not easy to find error. Ignoring return
values is just bad code. Now there certainly are case in which the
return value can be ignored safely, but then an OSL_VERIFY wouldn't be
necessary either.
If the return value can be ignored safely, that may be because you
really don't care, or because you fulfilled the preconditions to get a
well-known return value (e.g. success) every time.
In this latter case it is good practice to document this for maintenance
programmers by using an assertion. An assertion is better than a mere
comment here, because it will tell you when the assumption fails at
runtime (due to incorrect reasoning or maintenance changes).
The concise notation to do that without cluttering the code with
temporary variables for results you don't really use or extraneous
control structures is OSL_VERIFY.
Actually i think we should remove OSL_VERIFY for good.
I disagree.
Of course if there are cases like simple OSL_VERIFY(a==b), that
indicates that developers need to be better educated about our debug
macros and their meaning (and yes, consolidating the macro zoo should
help here).
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]
