assume, assert, enforce, @safe

IgorStepanov via Digitalmars-d digitalmars-d at puremagic.com
Thu Sep 18 15:07:09 PDT 2014


> The point is that using these enforce() statements means that 
> these methods cannot be nothrow, which doesn't seem 
> particularly nice if it can be avoided. Now, on the one hand, 
> one could say that, quite obviously, these methods cannot 
> control their input.  But on the other hand, it's reasonable to 
> say that these methods' input can and should never be anything 
> other than 100% controlled by the programmer.
>
> My take is that, for this reason, these should be asserts and 
> not enforce() statements.  What are your thoughts on the matter?

Assert's are disable by -release option. If you want to do check, 
and don't want to raise exception you can define special function 
like this:
import std.stdio;

void enforceNoThrow(bool pred, string msg, string file = 
__FILE__, uint line = __LINE__)
{
     if (!pred)
     {
         stderr.writefln("Fatal error: %s at %s:%s", msg, file, 
line);
         assert(0);
     }

}

void doSomething(int min, int middle, int max)
{
     enforceNoThrow(middle >= min && middle <= max, "middle out of 
bounds");
}

doSomething(1, 5, 3); //prints error message into stderr and 
terminate programm execution

This way is better for library code then asserts. Asserts should 
be used for catching internal bugs, but incorrect code is 
external bug (for extern library)



More information about the Digitalmars-d mailing list