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&quo
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
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".
Indee
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
AssertErr
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
suc
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.
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 det
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
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 beha
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 g
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
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 i
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 no
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) laun
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 "-relea
Hi!
I carefully read the
http://www.digitalmars.com/d/archives/digitalmars/D/assert_0_behavior_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
On 8/5/15 12:46 PM, Jonathan M Davis wrote:
Well, then please comment on the PR:
https://github.com/D-Programming-Language/druntime/pull/1337
It seems to me that the whole point of abort is to work around the fact
that Walter doesn't want assert(0) to print messages before the HLT
instru
't see anything
special about druntime or Phobos with regards to assertions
except for the fact that not much beyond the unit tests is going
to be using druntime/Phobos in debug mode, so assertions in
non-templated code simply aren't going to be doing anything
outside of the unit test
On 4 August 2015 at 00:54, Walter Bright via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> On 8/3/2015 8:50 AM, Steven Schveighoffer wrote:
>
>> 1. They aren't removed, they are replaced with a nearly useless segfault.
>>
>
> Not useless at all:
>
> 1. The program does not continue running
On Wednesday, 5 August 2015 at 06:37:21 UTC, Walter Bright wrote:
On 8/4/2015 8:26 PM, deadalnix wrote:
On Tuesday, 4 August 2015 at 20:40:47 UTC, deadalnix wrote:
Would you be of the opinion that assert should be a statement
rather than an
expression ? unreadability in the middle of expression
On Wednesday, 5 August 2015 at 08:09:49 UTC, Joseph Rushton
Wakeling wrote:
On Monday, 3 August 2015 at 23:57:36 UTC, Steven Schveighoffer
wrote:
At the very least, assert(0, "message") should be a compiler
error, the message is unused information.
Only if you compile in -re
On Monday, 3 August 2015 at 23:57:36 UTC, Steven Schveighoffer
wrote:
At the very least, assert(0, "message") should be a compiler
error, the message is unused information.
Only if you compile in -release mode. Without wanting to get
into a bikeshedding debate, I think that flag n
On Wednesday, 5 August 2015 at 05:51:32 UTC, Ola Fosheim Grøstad
wrote:
specification to the code for validation/documentation purposes.
Err... Verification, usually not validation.
On 8/4/2015 8:26 PM, deadalnix wrote:
On Tuesday, 4 August 2015 at 20:40:47 UTC, deadalnix wrote:
Would you be of the opinion that assert should be a statement rather than an
expression ? unreadability in the middle of expressions, especially when
evaluation order is not well defined, is close t
On Tuesday, 4 August 2015 at 23:06:44 UTC, John Colvin wrote:
I'm 90% on Walter's side here as he's right for the majority of
common cases, but on the other hand there are plenty of
situations where the boundary between code error and
environment error get blurred.
Well, the principled differ
On Tuesday, 4 August 2015 at 20:40:47 UTC, deadalnix wrote:
Would you be of the opinion that assert should be a statement
rather than an expression ? unreadability in the middle of
expressions, especially when evaluation order is not well
defined, is close to impossible to get right.
Ping ? W
On Wednesday, 5 August 2015 at 02:52:40 UTC, Jonathan M Davis
wrote:
On Tuesday, 4 August 2015 at 22:13:40 UTC, Steven Schveighoffer
wrote:
On 8/4/15 5:39 PM, Jonathan M Davis wrote:
I'm certainly not opposed to have a message be printed before
the HLT
instruction with assert(0), but I
On Tuesday, 4 August 2015 at 22:13:40 UTC, Steven Schveighoffer
wrote:
On 8/4/15 5:39 PM, Jonathan M Davis wrote:
I'm certainly not opposed to have a message be printed before
the HLT
instruction with assert(0), but I don't at all agree that the
fact that
the message is not seen i
On 8/4/15 7:33 PM, Walter Bright wrote:
On 8/4/2015 2:07 PM, Steven Schveighoffer wrote:
With druntime it's difficult to actually print the message
fprintf(stderr, "You left the headlights on.");
assert(0);
Going under the assumption that the program isn'
On 8/4/2015 4:56 PM, deadalnix wrote:
It seems that on american car, you bip as annoyingly as possible instead of
announcing what's wrong. Preferably for anything and its reverse.
It turns out you can make quite understandable speech simply by connecting an
on/off I/O port to a speaker. So the
On Tuesday, 4 August 2015 at 23:33:17 UTC, Walter Bright wrote:
On 8/4/2015 2:07 PM, Steven Schveighoffer wrote:
With druntime it's difficult to actually print the message
fprintf(stderr, "You left the headlights on.");
assert(0);
It seems that on american car, you bi
On 8/4/2015 4:37 PM, Walter Bright wrote:
On 8/4/2015 3:13 PM, Steven Schveighoffer wrote:
For instance:
https://github.com/D-Programming-Language/druntime/blob/master/src/core/time.d#L2283
This makes it seem like a message will be printed in the case where
ticksPerSecond was 0. but in reali
On 8/4/2015 3:13 PM, Steven Schveighoffer wrote:
For instance:
https://github.com/D-Programming-Language/druntime/blob/master/src/core/time.d#L2283
This makes it seem like a message will be printed in the case where
ticksPerSecond was 0. but in reality it simply throws a segfault.
That's a b
On 8/4/2015 2:07 PM, Steven Schveighoffer wrote:
With druntime it's difficult to actually print the message
fprintf(stderr, "You left the headlights on.");
assert(0);
On 8/4/2015 1:56 PM, Jonathan M Davis wrote:
I can definitely see an argument that we should be
printing out something before the HLT instruction in -release mode,
writeln("Somebody forgot to turn off the water.");
assert(0);
On Tuesday, 4 August 2015 at 22:06:06 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 4 August 2015 at 20:21:24 UTC, Walter Bright wrote:
On 8/3/2015 8:37 PM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
wrote:
The input/environment/code distinction does not work very
well.
Sure it does. If your user ev
On 8/4/15 5:39 PM, Jonathan M Davis wrote:
I'm certainly not opposed to have a message be printed before the HLT
instruction with assert(0), but I don't at all agree that the fact that
the message is not seen in -release is a reason not to have a message.
For instance:
https://gi
On Tuesday, 4 August 2015 at 20:21:24 UTC, Walter Bright wrote:
On 8/3/2015 8:37 PM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
wrote:
The input/environment/code distinction does not work very well.
Sure it does. If your user ever sees an assert failure message,
your program has a bug in it.
Yes
On Tuesday, 4 August 2015 at 21:07:20 UTC, Steven Schveighoffer
wrote:
On 8/4/15 4:56 PM, Jonathan M Davis wrote:
On Tuesday, 4 August 2015 at 20:48:52 UTC, Steven
Schveighoffer wrote:
On 8/4/15 4:43 PM, Steven Schveighoffer wrote:
I should say, any assert(0) with a message printed that is
On 8/4/15 4:56 PM, Jonathan M Davis wrote:
On Tuesday, 4 August 2015 at 20:48:52 UTC, Steven Schveighoffer wrote:
On 8/4/15 4:43 PM, Steven Schveighoffer wrote:
I should say, any assert(0) with a message printed that is possible to
trigger in release mode is an error. If you can ensure it&#
On Tuesday, 4 August 2015 at 20:48:52 UTC, Steven Schveighoffer
wrote:
On 8/4/15 4:43 PM, Steven Schveighoffer wrote:
I should say, any assert(0) with a message printed that is
possible to
trigger in release mode is an error. If you can ensure it's
only
possible to trigger when compil
On 8/4/15 4:43 PM, Steven Schveighoffer wrote:
I should say, any assert(0) with a message printed that is possible to
trigger in release mode is an error. If you can ensure it's only
possible to trigger when compiled in debug mode (or for unit tests),
then assert(0, msg) is fine.
In that
On Tuesday, 4 August 2015 at 20:23:53 UTC, Walter Bright wrote:
On 8/4/2015 4:53 AM, Steven Schveighoffer wrote:
Any assert(0) in druntime or phobos with a message printed is
an error. It's
compiled in release mode.
When you're debugging phobos, you aren't compiling in relea
On 8/4/15 4:23 PM, Walter Bright wrote:
On 8/4/2015 4:53 AM, Steven Schveighoffer wrote:
Any assert(0) in druntime or phobos with a message printed is an
error. It's
compiled in release mode.
When you're debugging phobos, you aren't compiling in release mode.
Unless you aren
On 8/4/2015 8:04 AM, Dicebot wrote:
Recently we had quite a lengthy discussion at work regarding possible guidelines
for using asserts, contracts and enforce (we have similar own implementation)
that would actually allow using -release flag for release builds. And got to
certain principles that I
On 8/4/2015 4:58 AM, Steven Schveighoffer wrote:
The only answer I can think of is to write a message to stderr, and then
assert(0) as meta suggested.
Print an error message and exit via abort() or whatever. No need to generate a
halt - the program hasn't entered an unknown state.
On 8/4/2015 4:53 AM, Steven Schveighoffer wrote:
Any assert(0) in druntime or phobos with a message printed is an error. It's
compiled in release mode.
When you're debugging phobos, you aren't compiling in release mode.
But I've also been of the opinion, not widely shared,
On 8/3/2015 8:37 PM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
wrote:
The input/environment/code distinction does not work very well.
Sure it does. If your user ever sees an assert failure message, your program has
a bug in it. Keep that in mind when designing the code, and the distinction will
b
On 8/4/15 7:53 AM, Steven Schveighoffer wrote:
Any assert(0) in druntime or phobos with a message printed is an error.
It's compiled in release mode.
I'll look through and find them, and rework them.
First stab: https://github.com/D-Programming-Language/druntime/pull/1337
-Steve
On Tuesday, 4 August 2015 at 14:40:16 UTC, Nick Sabalausky wrote:
On 08/03/2015 11:59 AM, Dicebot wrote:
General advice - simply don't ever use -release unless you
are _very_
sure about program correctness (to the point of 100% test
coverage and
previous successful debug runs)
This is very
On 08/03/2015 11:59 AM, Dicebot wrote:
General advice - simply don't ever use -release unless you are _very_
sure about program correctness (to the point of 100% test coverage and
previous successful debug runs)
This is very true. I never disable asserts or bounds checking for
exactly that re
throw from
core.time. Technically, usage of this unsupported clock will ALWAYS
throw, or NEVER throw. That's difficult to encode into the system.
The only answer I can think of is to write a message to stderr, and then
assert(0) as meta suggested.
-Steve
On 8/3/15 9:13 PM, Walter Bright wrote:
On 8/3/2015 5:25 PM, Ali Çehreli wrote:
On 08/03/2015 04:57 PM, Steven Schveighoffer wrote:
> At the very least, assert(0, "message") should be a compiler error,
the
> message is unused information.
Agreed.
No.
1. If you want the
On Tuesday, 4 August 2015 at 03:04:14 UTC, Dicebot wrote:
indeed. I remember Iain complaining about presence of HLT (and
saying he won't do that for gdc) for exactly this reason.
Yes. I think a lot of this confusion could have been avoided by
using "halt()" instead of
On Tuesday, 4 August 2015 at 02:37:00 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 3 August 2015 at 15:18:12 UTC, Dicebot wrote:
On Monday, 3 August 2015 at 14:34:52 UTC, Steven Schveighoffer
wrote:
Why do we do this?
Because all asserts must be completely removed in -release
Yet assert(0
On Monday, 3 August 2015 at 15:18:12 UTC, Dicebot wrote:
On Monday, 3 August 2015 at 14:34:52 UTC, Steven Schveighoffer
wrote:
Why do we do this?
Because all asserts must be completely removed in -release
Yet assert(0) effectively mean "unreachable code" (it is
actually defined t
On 8/3/2015 5:25 PM, Ali Çehreli wrote:
On 08/03/2015 04:57 PM, Steven Schveighoffer wrote:
> At the very least, assert(0, "message") should be a compiler error, the
> message is unused information.
Agreed.
No.
1. If you want the message, do not use -release.
2. Do no
that supports clock_gettime, which is immutable and can be read
easily at startup. However, how we handled the case where a clock could not be
fetched is to assert(0, "don't support clock " ~ clockname).
The clear expectation was that the message will be printed (along with file/line
On Monday, 3 August 2015 at 23:57:36 UTC, Steven Schveighoffer
wrote:
OK, this brings up another debate. The thing that triggered all
this is an issue with core.time, see issue
https://issues.dlang.org/show_bug.cgi?id=14863
[...]
Why not just " stderr.writeln(errMsg); assert(0);"?
On 08/03/2015 04:57 PM, Steven Schveighoffer wrote:
> At the very least, assert(0, "message") should be a compiler error, the
> message is unused information.
Agreed.
How about dumping the message to stderr as a best effort if the message
is a literal? Hm... On the other
At that
point, I'd rather you spend as much resources telling me what went wrong
as possible. More info the better.
Now, if it's expensive to include the throw vs. not including it (I
don't know), then that's a fair point. If it means an extra few
instructions to set up the
On 8/3/2015 8:50 AM, Steven Schveighoffer wrote:
1. They aren't removed, they are replaced with a nearly useless segfault.
Not useless at all:
1. The program does not continue running after it has failed. (Please, let's not
restart that debate.
2. Running it under a debugger, the location of
On 8/3/15 11:59 AM, Dicebot wrote:
General advice - simply don't ever use -release unless you are _very_
sure about program correctness (to the point of 100% test coverage and
previous successful debug runs)
So in other words, only release code that has no bugs. Got it ;)
-Steve
. They aren't removed, they are replaced with a nearly useless segfault.
2. If we are going to put something in there instead of "assert", why
not just throw an error?
Effectively:
assert(0, msg)
becomes a fancy way of writing (in any mode, release or otherwise):
throw new
General advice - simply don't ever use -release unless you are
_very_ sure about program correctness (to the point of 100% test
coverage and previous successful debug runs)
y are replaced with a nearly useless
segfault.
2. If we are going to put something in there instead of
"assert", why not just throw an error?
Effectively:
assert(0, msg)
becomes a fancy way of writing (in any mode, release or
otherwise):
throw new AssertError(msg);
This is actually th
o put something in there instead of "assert", why
not just throw an error?
Effectively:
assert(0, msg)
becomes a fancy way of writing (in any mode, release or otherwise):
throw new AssertError(msg);
This is actually the way I thought it was done.
-Steve
On Monday, 3 August 2015 at 14:34:52 UTC, Steven Schveighoffer
wrote:
Why do we do this?
Because all asserts must be completely removed in -release
Yet assert(0) effectively mean "unreachable code" (it is actually
defined that way in spec) and thus it is possible to ensure extra
If you compile and run the following code, what happens?
void main()
{
assert(0, "error message");
}
answer: it depends. On OSX, if you compile this like so:
dmd testassert.d
./testassert
You get this message + stack trace:
core.exception.AssertError@testassert.d(3): error me
;t we throw UTFException instead of assert(0) in
> stride,
> > etc ?
>
> std.utf only uses assert(0) when that code should be unreachable. It's
> used to
> catch bugs in the implementation, not in a function's input. If anything in
> std.utf ever hits an assert(0),
On Tuesday, December 10, 2013 15:52:06 Timothee Cour wrote:
> in std.utf shouldn't we throw UTFException instead of assert(0) in stride,
> etc ?
std.utf only uses assert(0) when that code should be unreachable. It's used to
catch bugs in the implementation, not in a function'
in std.utf shouldn't we throw UTFException instead of assert(0) in stride,
etc ?
72 matches
Mail list logo
