[Coin-lpsolver] Assert Problems

Lou Hafer lou at cs.sfu.ca
Wed Mar 2 16:25:03 EST 2005


	John writes
	
> I can see three sorts of uses of assert -
> 1) Double checking on some logical error - in my case that might be an 
> array that is marked as all zero when it is not.  This is sometimes but 
> not always on a -Dxxx_DEBUG flag given to compiler.
> 2) Something that should not happen but the code will recover - it may 
> have happened once and I want to track it down.
> 3) Something that should not happen but the code can't recover.

	Seems to me that type 1 & 2 errors are the business of the developer,
with the proviso that there should be a compile time flag to disable them
when speed is of the essence. Or turn it around -- at least for type 2,
they're off by default unless someone explicitly asks for a debugging build.

	Type 3 errors for me are ``something I didn't anticipate and/or thought 
was impossible when I wrote the code.'' For these, I'm with JP --- we should 
beef up CoinError to be more useful, and use it.
	
	My suggestion for enhancement would be to add something a bit more
computer-friendly.  Maybe a field that broadly classifies the error:
bad/unexpected input, numerical problem, internal confusion ... Something
that would give client code at least a hint to begin error recovery, should
it want to attempt it.

						Lou




More information about the Clp mailing list