Program logic bugs vs input/environmental errors

Walter Bright via Digitalmars-d digitalmars-d at puremagic.com
Sun Nov 9 13:33:46 PST 2014


On 11/7/2014 7:00 AM, Bruno Medeiros wrote:
> Let me give an example:
>
> double sqrt(double num) {
>    assert(num >= 0);
>    ...
>
> With just this, then purely from a compiler/language viewpoint, if the assert is
> triggered the *language* doesn't know if the whole program is corrupted
> (formatting the hard disk, etc.), or if the fault is localized there, and an
> error/exception can be thrown cleanly (clean in the sense that other parts of
> the program are not corrupted).
>
> So the language doesn't know, but the *programmer* can make a reasoning in each
> particular assert of which domains/components of the program are affected by
> that assertion failure. In the sqrt() case above, the programmer can easily
> state that the math library that sqrt is part of is not corrupted, and its state
> is not totally unknown (as in, it's not deadlocked, nor is it formatting the
> hard disk!).

Making such an assumption presumes that the programmer knows the SOURCE of the 
bug. He does not. The source could be a buffer overflow, a wild pointer, any 
sort of corruption.


> Very well then. But then we'll get to the point where enforce() will become much
> more popular than assert to check for contract conditions. assert() will be
> relegated to niche and rare situations where the program cant really know how to
> continue/recover cleanly (memory corruption for example).
>
> That idiom is fine with me actually - but then the documentation for assert
> should reflect that.

I created this thread because it is an extremely important topic. It has come up 
again and again for my entire career.

There is no such thing as knowing in advance what caused a bug, and that the bug 
is "safe" to continue from. If you know in advance what caused it, then it 
becomes expected program behavior, and is not a bug.

assert() is for bug detection, detecting state that should have never happened. 
By definition you cannot know it is "safe", you cannot know what caused it.

enforce() is for dealing with known, expected conditions.


More information about the Digitalmars-d mailing list