Re: the java assert mechanism: is it useful?

On Mon, 4 Aug 2008, marlow.andrew@googlemail.com wrote:


I haven't ever used it.

I think the way to think of java assertions is as tiny unit tests which
are embedded in the application code. If you had a class like:

public class OldMoney {
    private int pounds ; // must be >= 0
    private int shillings ; // must be >=0, <20
    private int pence ; // must be >=0, <12

    public int getPriceInPence() {
        return (((pounds * 20) + shillings) * 12) + pence ;
    }
}

You might write a unit test that looked like:

public void testMoneyComponentCounts() {
    OldMoney cash = somehowGetSomeMoney() ;
    assertGreaterThanZero(cash.getPounds()) ;
    assertInBetweenInclusive(0, cash.getShillings(), 19) ;
    assertInBetweenInclusive(0, cash.getPence(), 11) ;
}

With assertions, you could write:

    public int getPriceInPence() {
        assert pounds >= 0 ;
        assert (shillings >= 0) && (shillings < 20) ;
        assert (pence >= 0) && (pence < 12) ;
        return (((pounds * 20) + shillings) * 12) + pence ;
    }

Which would do much the same thing, but would run every time you called
that method, if you had assertions switched on.

It'd be nice if you could write assertions at class rather than method
level, and have them evaluated, say, every time a method on an object of
that class was called. Like:

public class OldMoney {
    private int pounds ; // must be >= 0
    assert pounds >= 0 ;
    private int shillings ; // must be >=0, <20
    assert (shillings >= 0) && (shillings < 20) ;
    private int pence ; // must be >=0, <12
    assert (pence >= 0) && (pence < 12) ;
}

The compiler would deal with them in a similar manner to field
initializer expressions - collect them together and invisibly prepend
them to every method body. Or perhaps the end of every method body. Or
both. Who knows.