[dmd-internals] changeset 455

[Sean Kelly]

On May 2, 2010, at 1:23 PM, Walter Bright wrote:
> 
> Andrei Alexandrescu wrote:
>> Since we've been looking into this now and we have a solution in our collective mental caches, is there please a chance to effect this change for this beta? I'm telling you, it is an _important_ step forward in unittesting D programs.
>> 
> 
> One thing I should mention is that dmd now calls a different function for unittest asserts than the asserts normally do, and it does not regard those calls as "terminating" calls. This means that the unittest behavior can now be controlled by adjusting the runtime library, without affecting the assert failure code.

I think the current behavior is a good first step, but should probably be modified a bit further.  For example:

    void fnA()
    {
        assert( false, "fnA 1" );
        assert( false, "fnA 2 ");
    }

    unittest
    {
        assert( false, "unittest 1" );
        assert( false, "unittest 2" );
        fnA();
    }

    unittest
    {
        assert( false, "unittest 3" );
    }

    void main()
    {
    
    }

Running this will print:

    test.d(9): unittest 1
    test.d(10): unittest 2
    core.exception.AssertError at test.d(3): fnA 1

So if an assert error occurs inside some code being tested, the app will still exit.  I tried modifying the unit testing code to eat the exception and continue, but then it simply prints:

    test.d(9): unittest 1
    test.d(10): unittest 2

So the best we can currently do is move on to test another module--there's no way to execute the remaining unit tests within the module.  Could we perhaps have an array of unittests within the ModuleInfo struct instead of just a single function pointer?  Or is the rationale really that if implementation code throws, the app should assume it's in an invalid state and exit?