Is the fact that:

    void f() nothrow {
    	    assert(1 == 0);
    }

    int main() {
    	    f();
    	    return 0;
    }

compiles fine but at run time f does indeed throw an exception what should happen? If it is what does nothrow actually mean?

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Thursday, 8 September 2016 at 11:40:17 UTC, Russel Winder wrote:
> Is the fact that:
>
>     void f() nothrow {
>     	    assert(1 == 0);
>     }
>
>     int main() {
>     	    f();
>     	    return 0;
>     }
>
> compiles fine but at run time f does indeed throw an exception what should happen? If it is what does nothrow actually mean?

f() is nothrow because assert() throws an "AssertError" not an "Exception". Since Error descendants are not recoverable the program usually crashes.

On Thursday, 8 September 2016 at 11:45:32 UTC, Basile B. wrote:
> f() is nothrow because assert() throws an "AssertError" not an "Exception". Since Error descendants are not recoverable the program usually crashes.

The program is guaranteed to crash unless you catch the error (not recommended).

On Thursday, 8 September 2016 at 11:40:17 UTC, Russel Winder wrote:
> Is the fact that:
>
>     void f() nothrow {
>     	    assert(1 == 0);
>     }
>
>     int main() {
>     	    f();
>     	    return 0;
>     }
>
> compiles fine but at run time f does indeed throw an exception what should happen? If it is what does nothrow actually mean?

To expand on the previous correct answers, nothrow is about not throwing Exceptions. Exceptions are part of the normal flow of the program: they are used to signal recoverable errors, much like error codes.

Errors, on the other hand, are unrecoverable system failures that should not be catched (catching them is undefined behaviour, I think) and will surely lead to a crash. Errors are not covered by nothrow.

Asserts throw Errors, not Exceptions. The reason is that asserts are used to test conditions that must hold, at the point that an optimizing compiler can analyze the expression inside the assert and optimize the executable based on the truthness of that condition. So if an assert is found false at runtime, the code may not be able to work at all. That's why asserts throw Errors and not Exceptions.

On Thu, Sep 08, 2016 at 12:07:43PM +0000, Lodovico Giaretta via Digitalmars-d-learn wrote: [...]
> To expand on the previous correct answers, nothrow is about not throwing Exceptions. Exceptions are part of the normal flow of the program: they are used to signal recoverable errors, much like error codes.

Yes.


> Errors, on the other hand, are unrecoverable system failures that should not be catched (catching them is undefined behaviour, I think) and will surely lead to a crash. Errors are not covered by nothrow.
[...]

Yes.

Well, you *can* catch Errors, but the program may not be in a consistent state, as dtors and such may not have been invoked, so what you can do in the catch block should generally be limited to spitting out an error message or writing to an error log (though it's arguable whether it's a good idea to open files at this point!), then aborting the program ASAP. It's probably a bad idea to write out data to data files, as the data may be in a corrupted state at that point. Continuing after catching an Error is Undefined Behaviour.


T

-- 
Those who don't understand Unix are condemned to reinvent it, poorly.