How do you test pre-/post-conditions and invariants?

Jonathan M Davis jmdavisProg at gmx.com
Sat Feb 26 17:41:31 PST 2011


On Saturday 26 February 2011 08:23:41 David Nadlinger wrote:
> On 2/26/11 4:08 PM, Magnus Lie Hetland wrote:
> > On 2011-02-26 15:20:19 +0100, David Nadlinger said:
> >> On 2/26/11 1:15 PM, Jonathan M Davis wrote:
> >>> [...] And from a perfectly practical standpoint, as soon as your code
> >>> ends
> >>> up in a library, assertions are generally useless anyway,[...]
> >> 
> >> I don't quite think asserts are useless in libraries. If you need to
> >> care about performance in a library, you hit cases quite frequently
> >> where sanity-checking the input would be too expensive to be done in
> >> release mode, and thus you can't specify behavior on invalid input as
> >> part of your API using exceptions. Nevertheless, it is still useful to
> >> people using your library to get notified when they are messing
> >> something up as early as possible in debug mode, which is precisely
> >> what asserts are made for, at least in my opinion.
> > 
> > But that would only work if they had access to the source, or a version
> > not compiled in release mode, right?
> 
> True, but as shipping debug libraries and headers is precisely what SDKs
> are for, I don't see much of a problem there. Heck, even Microsoft's C
> Runtime comes with an extra debug version…

Sure, you _can_ use assertions in public APIs, but you _can't_ rely on them 
being there, because the programmer using the API could be using a release 
version.

If you really want to have an error for giving bad input, then it should be an 
Exception of some kind. Assertions are there for testing code. They go away. 
Also, it just plain looks bad when your library throws an AssertError. Since 
assertions are used to test the internal logic of your code, it makes it look 
like _your_ code is wrong rather than the code which is using your code.

You can't rely on assertions being in a library, so if you want those checks to 
be guaranteed to take place, you need to use exceptions. If you want the check 
to always take place, you need to use exceptions. If you want to report an input 
error as opposed to reporting a code logic error, then you should be using 
exceptions. So, assertions make great sense for testing that your code is 
correct, but when you hand it off to someone else to use, it shouldn't generally 
be throwing AssertErrors. There are times where that makes sense (particularly 
in code that _needs_ to be highly efficient and can't afford the extra checks in 
release mode), but at that point, you're saying that the check is _not_ part of 
the API (just an extra service to the programmer using it), and you're saying 
that you're willing to deal with programmers thinking that your code is faulty, 
because it's throwing AssertErrors.

What I've been saying is essentially how Phobos goes about dealing with 
assertions and exceptions in its functions.

- Jonathan M Davis


More information about the Digitalmars-d-learn mailing list