unittest vs exceptions?

[Era Scarecrow]

On Saturday, 4 August 2012 at 22:15:53 UTC, David Nadlinger wrote:
> On Saturday, 4 August 2012 at 22:09:03 UTC, Jonathan M Davis 
> wrote:
>> On Sunday, August 05, 2012 00:00:24 Maxime Chevalier wrote:
>>> How does unittest check for success/failure? Does assert 
>>> throw a special kind of error class when it fails? How would 
>>> you check that some code didn't throw an exception, or did 
>>> throw an exception?

>> assert throws an AssertError. The unittest failed message is 
>> its message, so if it's never thrown, then you won't get that 
>> message. And if an exception is thrown, then the assertion 
>> won't fail, so no AssertError will be thrown, just the 
>> exception that your function threw.

> A failed unit test really just means that a unit test block is 
> left via an exception. Currently, it just bubbles up to the 
> druntime main(), where it is printed to console and causes a 
> non-zero exit code, but future unit test frameworks could 
> handle this in a more advanced way.

  Not if it's static asserts :) Unless I'm wrong, I've recently 
used a few static asserts to ensure certain combinations of code 
don't compile (on purpose). This is important for proving the 
logic works the way it is suppose to. Sorta following TDPL 
example of is(typof() == bool) (pg 141):

   const int a = 42;

   static assert(is(typeof(a = 24) == bool) == false,
     "constness from 'a' not honored.");

  Although it seems like a small silly example, but when you 
include something generated for a mixin or template functions it 
becomes a very different story. Plus you'd get your warnings and 
errors during compiling and not runtime (find bugs faster?)