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?

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.

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

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.

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

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.

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

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?

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).

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.