Assert and the optional Message

Timon Gehr timon.gehr at gmx.ch
Fri Mar 9 07:07:10 PST 2012


On 03/09/2012 03:24 PM, Jacob Carlborg wrote:
> On 2012-03-09 15:13, Timon Gehr wrote:
>> 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.
>
> Then way is it an error?

So that it does not get caught by catch(Exception){}.

> I still want it to call finally blocks, scope
> statements, and destructors.
>

I have never actually observed that those are not run for assertion 
failures.


More information about the Digitalmars-d-learn mailing list