Contracts + Assert

Jarrett Billingsley kb3ctd2 at yahoo.com
Wed Oct 31 05:58:50 PDT 2007


"Daniel Keep" <daniel.keep.lists at gmail.com> wrote in message 
news:fg93ci$1plr$1 at digitalmars.com...

> This, my friend, is the $60,000,000,000 question, and something I've
> struggled with myself.

I see expensive questions have also felt the effects of inflation.  ;)

> The problem is that almost any rule you come up with ends up being
> applicable to both contracts and in-function exceptions.
>
> Another issue is that asserts disappear when you throw -release.  Now,
> the idea that you can remove the "training wheels" when the program is
> debugged is nice in theory, but how many pieces of software do you know
> that do not have a *single* bug in them?  What's more, if there is a bug
> that your asserts haven't caught in normal testing, odds are it's an
> obscure, hard to find bug.  If that's the case, the last thing you want
> to do is remove the asserts, as they're your best tool for figuring out
> what's gone wrong.  A debugger doesn't count because you can't really
> ask a user to start up your program inside one.
>
> For me, I'll likely be one of those people who uses contracts all over
> the place, and never uses the -release switch.  In that scenario,
> contracts are useful for distinguishing interface-checking code (like
> making sure arguments are within range, etc.) from more general stuff
> (like making sure operations succee.)

This is why I think there needs to be more granularity in the compiler 
options.  If you look at the DMD source, you'll see that the compiler has 
separate options for assert, invariants, in, out, array bounds, and "switch 
without a default," but -debug and -release enable or diable them all as a 
chunk.  All that has to happen is for them to be split into multiple 
switches, so we can turn off some stuff but leave asserts or something. 




More information about the Digitalmars-d-learn mailing list