www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Catching Errors

reply Jack Stouffer <jack jackstouffer.com> writes:
 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?
Jan 19 2017
next sibling parent Dominikus Dittes Scherkl <Dominikus.Scherkl continental-corporation.com> writes:
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.
Jan 19 2017
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
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
Jan 19 2017
next sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
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.
Jan 19 2017
parent reply Jacob Carlborg <doob me.com> writes:
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
Jan 19 2017
parent Dicebot <public dicebot.lv> writes:
 protected-headers="v1"
From: Dicebot <public dicebot.lv>
Newsgroups: d,i,g,i,t,a,l,m,a,r,s,.,D
Subject: Re: Catching Errors
References: <zomdaoudcmavtjowjesb forum.dlang.org>
 <o5qmqv$16ef$1 digitalmars.com> <urgbypfrdofakngzgaki forum.dlang.org>
 <o5sfb6$18mh$1 digitalmars.com>
In-Reply-To: <o5sfb6$18mh$1 digitalmars.com>

--iQSUktMJNChEoMm7dcLFCEL44lPnJcgbp
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 01/20/2017 07:47 AM, Jacob Carlborg wrote:

 On 2017-01-19 16:46, Jack Stouffer wrote:
=20

 Or, you can mark that unit test block as  system and have  safe tests =




in

 another block.


=20
 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 wan=


t

 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.



--iQSUktMJNChEoMm7dcLFCEL44lPnJcgbp--
Jan 20 2017
prev sibling parent reply Atila Neves <atila.neves gmail.com> writes:
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
Jan 19 2017
parent Jacob Carlborg <doob me.com> writes:
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
Jan 19 2017
prev sibling next sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
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.
Jan 19 2017
parent Dukc <ajieskola gmail.com> writes:
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!
Jan 20 2017
prev sibling next sibling parent reply Jon Degenhardt <noreply noreply.com> writes:
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
Jan 19 2017
next sibling parent Kapps <opantm2+spam gmail.com> writes:
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?
Jan 19 2017
prev sibling next sibling parent Chris Wright <dhasenan gmail.com> writes:
On Fri, 20 Jan 2017 01:24:18 +0000, 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.
Jan 19 2017
prev sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
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.
Jan 19 2017
next sibling parent Jon Degenhardt <noreply noreply.com> writes:
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
Jan 19 2017
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
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
Jan 19 2017
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
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.
Jan 20 2017
next sibling parent reply Jacob Carlborg <doob me.com> writes:
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 :)



-- 
/Jacob Carlborg
Jan 20 2017
parent Adam D. Ruppe <destructionator gmail.com> writes:
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.
Jan 20 2017
prev sibling parent cym13 <cpicard openmailbox.org> writes:
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.
Jan 21 2017
prev sibling parent Chris Wright <dhasenan gmail.com> writes:
On Thu, 19 Jan 2017 14:29:46 +0000, 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).
Jan 19 2017