## digitalmars.D.learn - Functions, nothrow and assert

Russel Winder via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
```Is the fact that:

void f() nothrow {
assert(1 =3D=3D 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?

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
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
```
Sep 08 2016
Basile B. <b2.temp gmx.com> writes:
```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.
```
Sep 08 2016
Meta <jared771 gmail.com> writes:
```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).
```
Sep 08 2016
Lodovico Giaretta <lodovico giaretart.net> writes:
```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?

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.
```
Sep 08 2016
"H. S. Teoh via Digitalmars-d-learn" <digitalmars-d-learn puremagic.com> writes:
```On Thu, Sep 08, 2016 at 12:07:43PM +0000, Lodovico Giaretta via
Digitalmars-d-learn wrote:
[...]
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.
```
Sep 08 2016