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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 :) [1] http://dlang.org/phobos/core_exception.html#.AssertHandler -- /Jacob Carlborg
Jan 20
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
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
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