Re^2: C/C++ type assert() in Perl?

To me assert seems a silly way to debug. I mean you really have two options:

# Assert that the sun must rise in the next 24 hours.
    assert(($next_sunrise_time - time) < 24*60*60) if DEBUG;

    # Assert that your customer's primary credit card is active
    affirm {
        my @cards = @{$customer->credit_cards};
        $cards[0]->is_active;
    };
[download]

Option option one means you must almost know the variable at the time you write the code. Option two means you write a block of code to verify the contents. In my mind both types of var verification inline lead to a problem -- if you made a mistake dealing with the variable earlier in your code what makes you think your asserts will be golden? Adding code like this to a longer app just seems to possibly add more areas for failure. I would tend to use simple log prints on short apps, or on longer (more complex and reused) apps use a testing framework and the debugger to debug.

-Waswas

Comment on Re^2: C/C++ type assert() in Perl? Download Code

Replies are listed 'Best First'.
Re^3: C/C++ type assert() in Perl? by jdavidboyd (Friar) on Jun 10, 2004 at 23:59 UTC
I learned that asserts are supposed to be used to guarantee that the programmer did not make a mistake in his coding, and pass in bad values to a subroutine. In the case of the credit card, it would be pointless to assert() that the card is active. It would be prudent, however, to assert() that the program passed in a valid card to the subroutine that checks for active cards. Whether or not the card is active is not a programming error. Not passing a valid card in certainly is.	[reply]
Re^4: C/C++ type assert() in Perl? by waswas-fng (Curate) on Jun 17, 2004 at 16:50 UTC
My point being that asserts direct most programmers to copy and paste the same code that you should have used earlier on in your app to check if the card number was valid -- a regex or a sub -- whatever. This not only is redundant it also give the developer a false sense of a safety net (if his code did not verify the card correctly before it will/may not now). I think it is better to use a well established test harness to actually test a bad card number insert in multiple ways and verify the expected behavior happens. In my mind asserts are just as bad as mixing the display logic of web apps with the program logic -- in small apps just use print statements to debug or whatever you are comfortable with. In large complex apps do debugging and testing in specialized areas -- there is a reason it is called the debugger you know. -Waswas	[reply]