www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - assert(0)

reply Fyodor Ustinov <ufm ufm.su> writes:
Hi!

I carefully read the
http://www.digitalmars.com/d/archives/digitalmars/D/assert_0_
ehavior_269336.html and still have question.

Well. assert(0) located in very-very dangerous place. If we 
suddenly got to this place - Program should die immediately, 
otherwise there will be something terrible.

But without "-release" this place less dangerous? Why without 
"-release" this assert behaves like any other (throw exception 
and we can cath it, for example)?

I think assert(0) should have the same behavior with "-release" 
and without. May be "HLT instruction", may be "throw exception", 
but _the same_.

WBR,
     Fyodor.
Nov 07 2015
next sibling parent reply anonymous <anonymous example.com> writes:
On 07.11.2015 19:42, Fyodor Ustinov wrote:

 Well. assert(0) located in very-very dangerous place. If we suddenly got
 to this place - Program should die immediately, otherwise there will be
 something terrible.

 But without "-release" this place less dangerous? Why without "-release"
 this assert behaves like any other (throw exception and we can cath it,
 for example)?


Asserts throw Errors, not Exceptions. You should generally not catch 
Errors. That's just as dangerous without -release as with it.
Nov 07 2015
parent reply Fyodor Ustinov <ufm ufm.su> writes:
On Saturday, 7 November 2015 at 18:48:40 UTC, anonymous wrote:


 Asserts throw Errors, not Exceptions. You should generally not 
 catch Errors. That's just as dangerous without -release as with 
 it.


1. I should generally _not_, but I _can_.
2. Without "-release" assert(0) launches scope(exit), 
scope(failure) and "finally" blocks. I.e. we get a completely 
different behavior in "-release" and not "-release" mode.

WBR,
     Fyodor.
Nov 07 2015
next sibling parent reply David Nadlinger <code klickverbot.at> writes:
On Saturday, 7 November 2015 at 20:38:20 UTC, Fyodor Ustinov 
wrote:

 2. Without "-release" assert(0) launches scope(exit), 
 scope(failure) and "finally" blocks. I.e. we get a completely 
 different behavior in "-release" and not "-release" mode.


This is not guaranteed to happen for Errors either, which is part 
of the reason why you should pretty much never catch them.

  — David
Nov 07 2015
parent reply Fyodor Ustinov <ufm ufm.su> writes:
On Saturday, 7 November 2015 at 20:40:49 UTC, David Nadlinger 
wrote:

 On Saturday, 7 November 2015 at 20:38:20 UTC, Fyodor Ustinov 
 wrote:

 2. Without "-release" assert(0) launches scope(exit), 
 scope(failure) and "finally" blocks. I.e. we get a completely 
 different behavior in "-release" and not "-release" mode.


 This is not guaranteed to happen for Errors either, which is 
 part of the reason why you should pretty much never catch them.


"assert" not guaranteed caught by 
"scope(exit)/scope(failure)/finally" ???? Where I can read about 
this in documentation?

WBR,
     Fyodor.
Nov 07 2015
parent reply Kapps <opantm2+spam gmail.com> writes:
On Saturday, 7 November 2015 at 20:48:24 UTC, Fyodor Ustinov 
wrote:

 "assert" not guaranteed caught by 
 "scope(exit)/scope(failure)/finally" ???? Where I can read 
 about this in documentation?

 WBR,
     Fyodor.


Right. Errors indicate that something went fundamentally wrong in 
your program and no recovery is possible (indicates a programming 
error rather than an environmental error generally). So at this 
point the only thing to do is to close the program and stop 
execution. Theoretically anything might be wrong at this point, 
so even executing things like your finally or scope blocks could 
lead to corruption.
Nov 07 2015
parent Fyodor Ustinov <ufm ufm.su> writes:
On Saturday, 7 November 2015 at 20:50:02 UTC, Kapps wrote:


 Right. Errors indicate that something went fundamentally wrong 
 in your program and no recovery is possible (indicates a 
 programming error rather than an environmental error 
 generally). So at this point the only thing to do is to close 
 the program and stop execution. Theoretically anything might be 
 wrong at this point, so even executing things like your finally 
 or scope blocks could lead to corruption.


Wait-wait. Without "-release" we are not afraid of anything?

WBR,
     Fyodor.
Nov 07 2015
prev sibling parent reply anonymous <anonymous example.com> writes:
On 07.11.2015 21:38, Fyodor Ustinov wrote:

 1. I should generally _not_, but I _can_.


D lets you to shoot your own foot, yes. You're encouraged not to do it, 
though.


 2. Without "-release" assert(0) launches scope(exit), scope(failure) and
 "finally" blocks. I.e. we get a completely different behavior in
 "-release" and not "-release" mode.


Yeah, -release drastically changes how asserts behave. That's its 
purpose. A program should not fail asserts. If it does, that's a bug. In 
particular, assert(0) should never be reached. If it is reached, that's 
a bug.
Nov 07 2015
parent reply Fyodor Ustinov <ufm ufm.su> writes:
On Saturday, 7 November 2015 at 20:49:49 UTC, anonymous wrote:

 On 07.11.2015 21:38, Fyodor Ustinov wrote:

 1. I should generally _not_, but I _can_.


 D lets you to shoot your own foot, yes. You're encouraged not 
 to do it, though.


It's my opinion - shoot to my foot or not and select preffered 
weapon for it. :)


 2. Without "-release" assert(0) launches scope(exit), 
 scope(failure) and
 "finally" blocks. I.e. we get a completely different behavior 
 in
 "-release" and not "-release" mode.


 Yeah, -release drastically changes how asserts behave. That's 
 its purpose. A program should not fail asserts. If it does, 
 that's a bug. In particular, assert(0) should never be reached. 
 If it is reached, that's a bug.


We do not have way to in "scope(failure)" or "scope(exit)" detect 
- it's "assert" or "throw".

P.S.
I do not argue, "assert" - it's catch for fundamental programmers 
bug.
Nov 07 2015
next sibling parent anonymous <anonymous example.com> writes:
On 07.11.2015 22:00, Fyodor Ustinov wrote:

 We do not have way to in "scope(failure)" or "scope(exit)" detect - it's
 "assert" or "throw".


Ah, I get what you mean now. I think you have a point. Executing 
scope(failure/exit) code when an Error has been thrown may be bad. I'm 
not aware of the details, though.
Nov 07 2015
prev sibling parent reply David Nadlinger <code klickverbot.at> writes:
On Saturday, 7 November 2015 at 21:00:58 UTC, Fyodor Ustinov 
wrote:

 We do not have way to in "scope(failure)" or "scope(exit)" 
 detect - it's "assert" or "throw".


Indeed. But the point is that _all_ Errors (of which AssertError 
is one example) are throwable from `nothrow` functions, and as 
such might not unwind the stack as you would expect.

  — David
Nov 07 2015
parent reply rsw0x <anonymous anonymous.com> writes:
On Saturday, 7 November 2015 at 22:26:53 UTC, David Nadlinger 
wrote:

 On Saturday, 7 November 2015 at 21:00:58 UTC, Fyodor Ustinov 
 wrote:

 We do not have way to in "scope(failure)" or "scope(exit)" 
 detect - it's "assert" or "throw".


 Indeed. But the point is that _all_ Errors (of which 
 AssertError is one example) are throwable from `nothrow` 
 functions, and as such might not unwind the stack as you would 
 expect.

  — David


Dumb question, does nothrow affect codegen?
Nov 07 2015
next sibling parent Kapps <opantm2+spam gmail.com> writes:
On Sunday, 8 November 2015 at 02:51:33 UTC, rsw0x wrote:

 On Saturday, 7 November 2015 at 22:26:53 UTC, David Nadlinger 
 wrote:

 On Saturday, 7 November 2015 at 21:00:58 UTC, Fyodor Ustinov 
 wrote:

 We do not have way to in "scope(failure)" or "scope(exit)" 
 detect - it's "assert" or "throw".


 Indeed. But the point is that _all_ Errors (of which 
 AssertError is one example) are throwable from `nothrow` 
 functions, and as such might not unwind the stack as you would 
 expect.

  — David


 Dumb question, does nothrow affect codegen?


I don't know if it does right now, but in the future with things 
like RC I'd imagine it definitely would (ARC is cheaper if you 
can guarantee no exceptions). I feel like there is some cases 
right now where it does, but I don't know about that.
Nov 07 2015
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, 8 November 2015 at 02:51:33 UTC, rsw0x wrote:

 Dumb question, does nothrow affect codegen?


I'd be very surprised if it didn't. But even if it doesn't 
currently affect codegen, it likely will at some point in the 
future.

- Jonathan M Davis
Nov 08 2015
prev sibling parent reply Fyodor Ustinov <ufm ufm.su> writes:
Colleagues, IMHO:

If "assert" catch "fundamental programmers errors" - it should 
hang programm immediately with and without "-release".

If "assert" catch not "too fundamental" errors - assert(0) should 
emit "Error" in both cases.

Third option - assert(0) - it's a "special case" and halt program 
in both cases.

But there should't be so that in one case the "fundamental error" 
and the other "not fundamental".

It's my opinion.

WBR,
     Fyodor.
Nov 07 2015
parent Idan Arye <GenericNPC gmail.com> writes:
On Saturday, 7 November 2015 at 21:24:02 UTC, Fyodor Ustinov 
wrote:

 Colleagues, IMHO:

 If "assert" catch "fundamental programmers errors" - it should 
 hang programm immediately with and without "-release".

 If "assert" catch not "too fundamental" errors - assert(0) 
 should emit "Error" in both cases.

 Third option - assert(0) - it's a "special case" and halt 
 program in both cases.

 But there should't be so that in one case the "fundamental 
 error" and the other "not fundamental".

 It's my opinion.

 WBR,
     Fyodor.


I strongly disagree. Without `-release`, the job of "fundamental 
programmers errors" is not to stop the program and prevent 
farther corruption(which is pointless - how do you know executing 
the `scope(exit)` and `scope(failure)` blocks will increase the 
corruption? Maybe they'll reduce it?), because when you are 
developing you shouldn't work with the only copies of important 
data files. Without `-release`, the role of `assert`s(and 
`Error`s in general) is the help the programmer fix these bugs.

When I have a "fundamental programmer error" in my code, I prefer 
to get a stack trace from the exception mechanism than to find a 
core dump(that was hopefully generated) and rely on GDB's 
excellent support for D to analyze it.

Besides, there are some very specific cases where it's acceptable 
to catch `Error`s - one of them is when you have a logging 
mechanism that can log these errors in a way/place that's easier 
for you to read - and then of course re-throws them. Halting the 
program on errors prevents this logging mechanism from doing it's 
thing.
Nov 08 2015