How do we write an Assert function?

Let's try to use JScript to match the functionality of MFC's 'ASSERT()' or C++'s 'assert()' macro.

function assert (sCode) {

var RunMe = new Function ("return " + sCode + ";");

if (!RunMe()) throw sCode;

Quote:

}

assert ("true");

If the line fails, we throw a string describing the statement that we thought would pass. That's beautiful, right?

Nope. We can't call it like this:

assert ("GetStatus (aCnn, nPOID) == 'OPEN'");

Now we need to pass arguments (aCnn) into a string so the assertion.

Before I punt and simply write an Assert that takes a boolean argument and merely tests this, does anyone know any tricks I can use to enable Defensive Coding in JScript just like all the other modern languages use?

-- Phlip ======= http://www.*-*-*.com/ ~tegan/home.html =======

Tue, 17 Dec 2002 03:00:00 GMT

MS#2 / 3

How do we write an Assert function?

Quote:

> Newsgroupies:

> Let's try to use JScript to match the functionality of MFC's 'ASSERT()' or > C++'s 'assert()' macro.

Hi,

Firstly, you could probably get away with 'eval' rather than creating a new Function since you are only going to execute the code once.

Personally I am averse to putting function calls into ASSERTs because sooner or later you're going to use one that has side effects, and they you're program won't work when you're not in debug mode (I assume your actual assert() function tests for a DEBUG flag before executing the code, otherwise what's the point?)

Quote:

> Before I punt and simply write an Assert that takes a boolean argument and > merely tests this, does anyone know any tricks I can use to enable Defensive > Coding in JScript just like all the other modern languages use?

More generally though, I'm not sure why you are doing this. You have ASSERTs in C++ so that you can check pre- and post-conditions while debugging, but remove the checks in your retail builds FOR PERFORMANCE REASONS.

But your strategy won't really help with performance because you're going to incur the overhead of a run-time function call every time, regardless of whether the assert function actually does anything or not.

If you just want to know the line of code that caused the error, a better strategy (IMHO) is to write a custom throw function and use the de{*filter*}:

This won't help with performance, but when you are debugging it will break into the de{*filter*} (you can then use the stack trace to find out where it was called from) and when you aren't debugging it will just throw the error and continue as normal.

Peter

-- Peter J. Torr - Microsoft Windows Script Program Manager

Please do not e-mail me with questions - post them to this newsgroup instead. Thankyou!

Tue, 17 Dec 2002 03:00:00 GMT

Phli#3 / 3

How do we write an Assert function?

Quote:

> > Let's try to use JScript to match the functionality of MFC's 'ASSERT()' or > > C++'s 'assert()' macro. > Firstly, you could probably get away with 'eval' rather than creating a new > Function since you are only going to execute the code once.

Ja!

(But if I can't easily stealth the parameters in anyway, then{*filter*}it...)

Quote:

> Personally I am averse to putting function calls into ASSERTs because sooner > or later you're going to use one that has side effects, and they you're > program won't work when you're not in debug mode (I assume your actual > assert() function tests for a DEBUG flag before executing the code, > otherwise what's the point?)

Rule One: The Asserts are either short-n-sweet or in the UnitTest code, not the production code.

Rule Zero: Write the UnitTest code _before_ you write the production code.

<assertion performance tutorial snipped>

Quote:

> If you just want to know the line of code that caused the error, a better > strategy (IMHO) is to write a custom throw function and use the de{*filter*}:

Both JavaScript and its environs have dark corners that resist learning attempts. For example, if you had not told me about this 'de{*filter*}' keyword, I could never have found it. E-searches on the word "debug" would un-cork a flood!