On Monday, 24 February 2020 at 13:43:30 UTC, Adam D. Ruppe wrote:
On Monday, 24 February 2020 at 13:42:01 UTC, NaN wrote:
try { writeln(e.msg); }
try `writeln(e.toString());` instead.
msg only contains the message passed to the constructor by
itself, toString includes the file/line
On Monday, 24 February 2020 at 13:42:01 UTC, NaN wrote:
try { writeln(e.msg); }
try `writeln(e.toString());` instead.
msg only contains the message passed to the constructor by
itself, toString includes the file/line and stack trace members
too.
easiest way usually.
Normally a failed assert gives the file, line number and a stack
trace, but I hit one today that just prints..
assertion failure
Im sure it is because it's in the WindowProc callback from the
OS. As the callback is nothrow you need to catch and handle
anything there, you have to catch all
On Friday, 20 January 2017 at 14:22:23 UTC, Adam D. Ruppe wrote:
On Friday, 20 January 2017 at 07:50:23 UTC, Jacob Carlborg
wrote:
That doesn't work well with a unit test framework that want to
catch assertions to be able to continue with other tests.
I'd suggest writing a new assert handler
On Thursday, 19 January 2017 at 16:55:18 UTC, Jack Stouffer wrote:
Ok, very visible idiotic moment here:
This is already the rule.
Just got the same (glad) feeling when I was reporting about an
apparently dangerous feature of RefCounted payload access being
@safe. I started to write a test
On Friday, 20 January 2017 at 17:00:12 UTC, Jacob Carlborg wrote:
Unfortunately setting a new assert handler requires it to be
nothrow [1].
WTF. I guess I see why, assert is assumed to be nothrow and used
in those statically marked blocks, but ugh.
AST macros :)
Yeah, it could do it, but
On 2017-01-20 15:22, Adam D. Ruppe wrote:
I'd suggest writing a new assert handler for your framework that does
something different, then you can get a bit more control over it.
Unfortunately setting a new assert handler requires it to be nothrow
[1]. I would most likely want it to be throw
On Friday, 20 January 2017 at 07:50:23 UTC, Jacob Carlborg wrote:
That doesn't work well with a unit test framework that want to
catch assertions to be able to continue with other tests.
I'd suggest writing a new assert handler for your framework that
does something different, then you can
On 01/20/2017 07:47 AM, Jacob Carlborg wrote:
> On 2017-01-19 16:46, Jack Stouffer wrote:
>
>> Or, you can mark that unit test block as @system and have @safe tests in
>> another block.
>
> No, this is for when the framework is catching the exception. It needs
> to wrap _all_ unit test blocks in
On 2017-01-20 03:11, Adam D. Ruppe wrote:
It is just that Errors are not necessarily *thrown*. The implementation
is allowed to immediately abort on them too - your catch has no
guarantee to actually run, whereas with Exceptions, they are.
That doesn't work well with a unit test framework
On 2017-01-19 17:22, Atila Neves wrote:
Just slap @trusted on the part of the framework that catches them.
Sure, but that doesn't help with the plan [1] making Errors unable to be
caught even in system code.
[1] Note sure if it's really the plan but it's been talked about
--
/Jacob
On 2017-01-19 16:46, Jack Stouffer wrote:
Or, you can mark that unit test block as @system and have @safe tests in
another block.
No, this is for when the framework is catching the exception. It needs
to wrap _all_ unit test blocks in a try-catch. If an assert fails I want
the rest of the
On Friday, 20 January 2017 at 02:11:41 UTC, Adam D. Ruppe wrote:
On Friday, 20 January 2017 at 01:24:18 UTC, Jon Degenhardt
wrote:
Is there a place in the docs that describe the difference
between errors and exceptions? As to the particular example,
why is it unsafe to recover from attempting
On Friday, 20 January 2017 at 01:24:18 UTC, Jon Degenhardt wrote:
Is there a place in the docs that describe the difference
between errors and exceptions? As to the particular example,
why is it unsafe to recover from attempting to access memory
past the end of the array, as long as the access
On Fri, 20 Jan 2017 01:24:18 +, Jon Degenhardt wrote:
> As
> to the particular example, why is it unsafe to recover from attempting
> to access memory past the end of the array, as long as the access was
> prevented?
Because array bounds checking seems to be intended as an aid to find
bugs,
On Thu, 19 Jan 2017 14:29:46 +, Jack Stouffer wrote:
> From what I understand, the difference between an Exception and and
> Error is that Errors signal your program has entered into an invalid
> state.
That's the intent, but I don't think that matches reality.
> For example, going past the
On Friday, 20 January 2017 at 01:24:18 UTC, Jon Degenhardt wrote:
On Thursday, 19 January 2017 at 14:29:46 UTC, Jack Stouffer
wrote:
[...]
I think this is an area of D I haven't explored yet. Is there a
place in the docs that describe the difference between errors
and exceptions? As to the
On Thursday, 19 January 2017 at 14:29:46 UTC, Jack Stouffer wrote:
From what I understand, the difference between an Exception and
and Error is that Errors signal your program has entered into
an invalid state. For example, going past the end of an array
and attempting to access that memory.
On Thursday, 19 January 2017 at 14:29:46 UTC, Jack Stouffer wrote:
From what I understand, the difference between an Exception and
and Error is that Errors signal your program has entered into
an invalid state. For example, going past the end of an array
and attempting to access that memory.
On Thursday, 19 January 2017 at 15:43:26 UTC, Jacob Carlborg
wrote:
On 2017-01-19 15:29, Jack Stouffer wrote:
If this is the case, would it not make sense to make it
illegal to catch
Errors in @safe code?
There's the issue with AssertError, which is useful for a unit
test framework to
On Thursday, 19 January 2017 at 15:43:26 UTC, Jacob Carlborg
wrote:
On 2017-01-19 15:29, Jack Stouffer wrote:
If this is the case, would it not make sense to make it
illegal to catch
Errors in @safe code?
There's the issue with AssertError, which is useful for a unit
test framework to
On 2017-01-19 15:29, Jack Stouffer wrote:
If this is the case, would it not make sense to make it illegal to catch
Errors in @safe code?
There's the issue with AssertError, which is useful for a unit test
framework to catch. Perhaps it could throw an AssertException instead
when the
On Thursday, 19 January 2017 at 14:29:46 UTC, Jack Stouffer wrote:
From what I understand, the difference between an Exception and
and Error is that Errors signal your program has entered into
an invalid state. For example, going past the end of an array
and attempting to access that memory.
From what I understand, the difference between an Exception and
and Error is that Errors signal your program has entered into an
invalid state. For example, going past the end of an array and
attempting to access that memory. On the flip side, Exceptions
signal that something out of the
https://issues.dlang.org/show_bug.cgi?id=12646
Issue ID: 12646
Summary: Catching Errors should imply nothrow
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: rejects-valid
https://issues.dlang.org/show_bug.cgi?id=12646
Andrej Mitrovic andrej.mitrov...@gmail.com changed:
What|Removed |Added
Blocks||12645
--
https://issues.dlang.org/show_bug.cgi?id=12646
Andrej Mitrovic andrej.mitrov...@gmail.com changed:
What|Removed |Added
Assignee|nob...@puremagic.com
https://issues.dlang.org/show_bug.cgi?id=12646
Andrej Mitrovic andrej.mitrov...@gmail.com changed:
What|Removed |Added
Keywords||pull
---
https://issues.dlang.org/show_bug.cgi?id=12646
Andrej Mitrovic andrej.mitrov...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
https://issues.dlang.org/show_bug.cgi?id=12646
Kenji Hara k.hara...@gmail.com changed:
What|Removed |Added
Blocks|12645 |
--
30 matches
Mail list logo
