These are the things I think are important to provide an assert
functionality, which would also be very helpful in some cases in
adding a unit test suite. These are relatively independent!
1) context macros, like __FILE__ and __LINE__ in C, which the
compiler will replace with the appropriate details. I suggest:
__LINE__ to return the line number within the method
__EXPR__ the text of the assertion test (see below)
__METHOD__ returns the method name
__METHODOWNER__ or some other generic word, to indicate the module,
class or window containing the method. We do NOT want to have to
change this word depending on context.
__STACK__ to get a stack dump (not so sure about this)
The main reason for these being independent is they allow us to write
unit test structures that also extract this information, not
necessarily relying on the assertion mechanism.
Note instead of the c-style __BLAH__ macros, they might be more RB-
ish as #Line, #LineSource etc.
2) an assert feature which
i) takes a condition,
ii) allows you to compose a text param, so you can use the above
macros. If you do not supply this param it defaults to:
"assertion __EXPR__ failed at line __LINE__ of __METHOD__ within
__METHODOWNER__" + endofline + __STACK__
iii) Follows the MFC pattern of having Assert and Verity where Assert
is only active in debug builds (and has zero impact in release) and
Verity is always active.
3) A replaceable AssertionHandler. This could be a method of the App
object. By default it is a system.debuglog write followed by
application stop. The reason for using a very low-requirement
reporting mechanism by default is to increase its chances of
successfully reporting. It is quite likely that a program triggering
an assert has already damaged things to the point where a window
might not launch.
We can't add 1 & 2 outside of the compiler.
I do not think it is appropriate for RS to tell us how to do
assertions, whether they should always be active etc. That is why
there is a choice of macros (incidentally, a C programmer is always
able to redefine the assert macro to their own rules, so it CAN
always be active).
I would be VERY happy to see something like the above and I truly
believe that level of detailed factoring is necessary.
Andy Dent
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
