Re: catching Errors in OS callbacks how to print stack trace?

2020-02-24 Thread NaN via Digitalmars-d-learn 

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 and stack trace members 
too.


easiest way usually.


That worked thanks!

Re: catching Errors in OS callbacks how to print stack trace?

2020-02-24 Thread Adam D. Ruppe via Digitalmars-d-learn 

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.

catching Errors in OS callbacks how to print stack trace?

2020-02-24 Thread NaN via Digitalmars-d-learn 
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 throwables or else it just 
hangs when you hit an assert. But how do I get it to print the 
full file, line, and stack trace?


Here's my window proc...

extern(Windows)
LRESULT WindowProc(HWND hwnd, UINT msg, WPARAM wparam, LPARAM 
lparam) nothrow

{
try
{
auto window = cast(Window) (cast(void*) 
GetWindowLongPtr(hwnd, 0));


if (window is null)
return DefWindowProcA(hwnd, msg, wparam, lparam);
else
return window.windowProc(msg, wparam, lparam);
}
catch (Throwable e)
{
try { writeln(e.msg); }
catch(Exception what) {}
PostQuitMessage(0);
return 0;
}
}

Re: Catching Errors

2017-01-21 Thread cym13 via Digitalmars-d 

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 for your framework 
that does something different, then you can get a bit more 
control over it.


Though, the built in assert is underpowered regardless... oh, 
how I wish it even had the convenience of C's assert, but I 
really want it to go a step further and show the values as well 
as the code that is failing.


int a = 0;
int b = 1;
assert(a == b);

Assertion `a == b` failed: test.d(3)
 a = 0
 b = 1


Default asserts can do that (not sure since when as I just 
discovered that recently):


int a=0;
int b=1;
assert(a==b, format("a=%d, b=%d", a, b));

core.exception.AssertError@/tmp/test.d(18): a = 0, b = 1

I know unit test frameworks tend to offer their own functions 
to get closer to this but it'd be compelling to me if it just 
worked with the built in too.




Oh well, that's not today, but doing your own assert handler 
that just prints and continues, or prints and aborts the 
current test while continuing with the next or something like 
that is doable and perhaps useful.

Re: Catching Errors

2017-01-20 Thread Dukc via Digitalmars-d 

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 case and noticed that while 
payload IS @safe, creating and destroying a RefCounted is not. 
Nothing to worry about!

Re: Catching Errors

2017-01-20 Thread Adam D. Ruppe via Digitalmars-d 

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 since assert is built in, the compiler 
can just do it for us too.



but meh.

Re: Catching Errors

2017-01-20 Thread Jacob Carlborg via Digitalmars-d 

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 an exception instead of an 
error to bail out of the current test, but continue with the rest of the 
tests.


Sure, it's possible to use a completely different than "assert", but 
that feels quite a shame when we have a built-in keyword for this purpose.



Though, the built in assert is underpowered regardless... oh, how I wish
it even had the convenience of C's assert, but I really want it to go a
step further and show the values as well as the code that is failing.

int a = 0;
int b = 1;
assert(a == b);

Assertion `a == b` failed: test.d(3)
 a = 0
 b = 1


AST macros :)

[1] http://dlang.org/phobos/core_exception.html#.AssertHandler

--
/Jacob Carlborg

Re: Catching Errors

2017-01-20 Thread Adam D. Ruppe via Digitalmars-d 

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 get a bit more control 
over it.


Though, the built in assert is underpowered regardless... oh, how 
I wish it even had the convenience of C's assert, but I really 
want it to go a step further and show the values as well as the 
code that is failing.


int a = 0;
int b = 1;
assert(a == b);

Assertion `a == b` failed: test.d(3)
 a = 0
 b = 1


I know unit test frameworks tend to offer their own functions to 
get closer to this but it'd be compelling to me if it just worked 
with the built in too.




Oh well, that's not today, but doing your own assert handler that 
just prints and continues, or prints and aborts the current test 
while continuing with the next or something like that is doable 
and perhaps useful.

Re: Catching Errors

2017-01-20 Thread Dicebot via Digitalmars-d 
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 a try-catch. If an assert fails I want
> the rest of the unit tests to be able to run.

And if one is to take language spec by heart, currently ANY framework
that implements it relies on undefined behavior :(

Usage of `assert` in unittests was quite a mistake.




signature.asc
Description: OpenPGP digital signature

Re: Catching Errors

2017-01-19 Thread Jacob Carlborg via Digitalmars-d 

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 that want to catch 
assertions to be able to continue with other tests.


--
/Jacob Carlborg

Re: Catching Errors

2017-01-19 Thread Jacob Carlborg via Digitalmars-d 

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 Carlborg

Re: Catching Errors

2017-01-19 Thread Jacob Carlborg via Digitalmars-d 

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 unit tests to be able to run.


--
/Jacob Carlborg

Re: Catching Errors

2017-01-19 Thread Jon Degenhardt via Digitalmars-d 

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 to access memory 
past the end of the array, as long as the access was prevented?


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.


Thanks, that's helpful. I hadn't seen it before, but the 
documentation for Object.Error and Object.Exception is clear on 
the distinction (https://dlang.org/phobos/object.html#.Error). 
There the intent is clear that Object.Error is for "unrecoverable 
runtime errors", and "not safe to catch and handle".


An aside - The documentation I had read, in the Error Handling 
chapter of the Language Reference, 
https://dlang.org/spec/errors.html, is less crisp about this 
distinction than the documentation for Object.Error. Perhaps an 
opportunity to improve this part of the documentation.


--Jon

Re: Catching Errors

2017-01-19 Thread Adam D. Ruppe via Digitalmars-d 

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 was prevented?


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.

Re: Catching Errors

2017-01-19 Thread Chris Wright via Digitalmars-d 
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, a tool that you use during testing and development and turn off for 
production.

Disabling array bounds checks is too dangerous for me.

Re: Catching Errors

2017-01-19 Thread Chris Wright via Digitalmars-d 
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 end of an array and attempting to
> access that memory.

The program is in a well-defined state. In production, I want to catch 
and log that problem, move that work item into the dead letter queue, and 
move on.

There are other problems that lead to the program being in an 
unpredictable, possibly unusable state. This is primarily when the 
runtime produces an Error regarding its internal state (as opposed to 
parameter validation).

Re: Catching Errors

2017-01-19 Thread Kapps via Digitalmars-d 

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 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?


--Jon


It indicates a programming error. If you attempted to read past 
the end, what other invalid data did you end up actually 
succeeding reading?

Re: Catching Errors

2017-01-19 Thread Jon Degenhardt via Digitalmars-d 

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 the flip side, 
Exceptions signal that something out of the ordinary happened, 
but with proper handling the program can go on it's merry way. 
An example being entering 13 as a month in a std.datetime.Date.


If this is the case, would it not make sense to make it illegal 
to catch Errors in @safe code?


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 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?


--Jon

Re: Catching Errors

2017-01-19 Thread Jack Stouffer via Digitalmars-d 

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 the flip side, 
Exceptions signal that something out of the ordinary happened, 
but with proper handling the program can go on it's merry way. 
An example being entering 13 as a month in a std.datetime.Date.


If this is the case, would it not make sense to make it illegal 
to catch Errors in @safe code?


Ok, very visible idiotic moment here:

This is already the rule.

Re: Catching Errors

2017-01-19 Thread Atila Neves via Digitalmars-d 
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 catch. Perhaps it could throw an 
AssertException instead when the "unittest" flag is passed.


Just slap @trusted on the part of the framework that catches them.

Atila

Re: Catching Errors

2017-01-19 Thread Jack Stouffer via Digitalmars-d 
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 catch. Perhaps it could throw an 
AssertException instead when the "unittest" flag is passed.


Or, you can mark that unit test block as @system and have @safe 
tests in another block.

Re: Catching Errors

2017-01-19 Thread Jacob Carlborg via Digitalmars-d 

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 "unittest" flag is passed.


--
/Jacob Carlborg

Re: Catching Errors

2017-01-19 Thread Dominikus Dittes Scherkl via Digitalmars-d 

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 the flip side, 
Exceptions signal that something out of the ordinary happened, 
but with proper handling the program can go on it's merry way. 
An example being entering 13 as a month in a std.datetime.Date.


If this is the case, would it not make sense to make it illegal 
to catch Errors in @safe code?


I would say yes. This sounds plausible.

Catching Errors

2017-01-19 Thread Jack Stouffer via Digitalmars-d 
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 ordinary happened, but with 
proper handling the program can go on it's merry way. An example 
being entering 13 as a month in a std.datetime.Date.


If this is the case, would it not make sense to make it illegal 
to catch Errors in @safe code?

[Issue 12646] New: Catching Errors should imply nothrow

2014-04-25 Thread via Digitalmars-d-bugs 
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
  Severity: normal
  Priority: P1
 Component: DMD
  Assignee: nob...@puremagic.com
  Reporter: andrej.mitrov...@gmail.com

-
void func() { }

// ok
void test1() nothrow
{
try
{
func();
}
catch (Exception th)
{
}
}

// Error: function 'test.test2' is nothrow yet may throw
void test2() nothrow
{
try
{
func();
}
catch (Error th)
{
}
}

void main() { }
-

--

[Issue 12646] Catching Errors should imply nothrow

2014-04-25 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=12646

Andrej Mitrovic andrej.mitrov...@gmail.com changed:

   What|Removed |Added

 Blocks||12645

--

[Issue 12646] Catching Errors should imply nothrow

2014-04-25 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=12646

Andrej Mitrovic andrej.mitrov...@gmail.com changed:

   What|Removed |Added

   Assignee|nob...@puremagic.com|andrej.mitrov...@gmail.com

--

[Issue 12646] Catching Errors should imply nothrow

2014-04-25 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=12646

Andrej Mitrovic andrej.mitrov...@gmail.com changed:

   What|Removed |Added

   Keywords||pull

--- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com ---
https://github.com/D-Programming-Language/dmd/pull/3497

--

[Issue 12646] Catching Errors should imply nothrow

2014-04-25 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=12646

Andrej Mitrovic andrej.mitrov...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Andrej Mitrovic andrej.mitrov...@gmail.com ---
Sorry, invalid. Exception is derived from Throwable, not Error. My mistake.

--

[Issue 12646] Catching Errors should imply nothrow

2014-04-25 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=12646

Kenji Hara k.hara...@gmail.com changed:

   What|Removed |Added

 Blocks|12645   |

--