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.

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

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

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

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

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.

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.

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

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.

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!