Assert and the optional Message

[Timon Gehr]

On 03/09/2012 01:20 PM, Jacob Carlborg wrote:
> On 2012-03-09 12:12, Jonathan M Davis wrote:
>> On Friday, March 09, 2012 11:03:38 Regan Heath wrote:
>>> On Fri, 09 Mar 2012 08:20:33 -0000, Chris Pons<cmpons at gmail.com> wrote:
>>>> Any idea why, system("PAUSE") does work?
>>>
>>> As Jonathan says, assert throws AssertError... which means, if you
>>> wanted
>>> to you could catch it, for example...
>>>
>>> module asserting;
>>>
>>> import std.stdio;
>>> import core.exception;
>>>
>>> debug
>>> {
>>> import std.c.windows.windows;
>>> extern (C) int kbhit();
>>> }
>>>
>>> void main()
>>> {
>>> try
>>> {
>>> assert(false, "testing assert");
>>> }
>>> catch(AssertError e)
>>> {
>>> debug
>>> {
>>> writefln("Assertion failed: %s", e);
>>> writefln("Press any key to exit...");
>>> while(!kbhit())
>>> Sleep(1);
>>> }
>>> throw e;
>>> }
>>> }
>>>
>>> So, for debug builds your exe will output the assertion manually, and
>>> wait
>>> for a key press. Then re-throw the assertion (resulting in the d runtime
>>> outputting the assertion again). In release, no pause.
>>>
>>> Note: kbhit and Sleep are windows specific (sleep would be the unix
>>> equivalent, not sure on one for kbhit).
>>
>> Bet advised that catching anything not derived from Exception is
>> generally a
>> _bad_ idea (most of which are derived from Error), and AssertError is
>> _not_
>> derived from Exception but rather Error. AssertErrors are not
>> guaranteed to
>> invoke finally blocks, scope statements, or destructors. Your program
>> is in an
>> invalid state when you catch an Error. So, while it may work in this
>> particular case, it is _not_ something that you should be doing in
>> general. By
>> far the worst thing to do would be to catch an Error and then continue
>> executing. Errors are _supposed_ to kill your program.
>>
>> - Jonathan M Davis
>
> Then I would say it's bad design to have "assert" throw an AssertError.
> Whatever "assert" throws needs to be catchable, this is essential for
> writing unit test frameworks. It needs to be possible to write a unit
> test framework that catches all AssertErrors and prints a nice report at
> the end (or similar).
>

This is a special case. Jonathan was specifically referring to the 
general case.