On 05/31/2017 09:04 AM, Steven Schveighoffer wrote:
> 
> What are your thoughts?

+1 million. I *hate* D's notion of Error. Well, no...more correctly, I absolutely hate that it throws cleanup/unwinding straight out the window for many situations that can obviously be handled safely without the paranoid "ZOMG Sky Is Falling!!!!" overreaction that is baked into the design of Error. And that causes problems like the one you describe.

Kill it with fire!!!

A wrapper type seems like a plausable workaround, but I really, really dislike that it would ever be necessary to bother wrapping such a basic prevailant feature as...arrays, especially just to work around such a collosal misfeature.

And, as you describe in your reply to H.S. Teoh, the current behavior of Error can actually cause MORE damage than just rcovering from an obviously recoverable situation.

On Wednesday, 31 May 2017 at 17:13:08 UTC, Nick Sabalausky (Abscissa) wrote:
> On 05/31/2017 09:04 AM, Steven Schveighoffer wrote:
>> 
>> What are your thoughts?
>
> +1 million. I *hate* D's notion of Error. Well, no...more correctly, I absolutely hate that it throws cleanup/unwinding straight out the window for many situations that can obviously be handled safely without the paranoid "ZOMG Sky Is Falling!!!!" overreaction that is baked into the design of Error. And that causes problems like the one you describe.

To be fair, anything that can be handled in a sane&safe way should inherit from Exception, not from Error, so throwing away cleanup for Error makes sense, since an Error means the program is in an undefined state and should terminate asap.

On Wednesday, 31 May 2017 at 13:04:52 UTC, Steven Schveighoffer wrote:
> [...]
>
> What are your thoughts? Have you run into this? If so, how did you solve it?
>

It is not that accessing the array out of bounds *leading* to data corruption that is the issue here, but that in general you have to assume that the index *being* out of bounds is itself the *result* of *already occurred* data corruption; and if data corruption occurred for the index, you *cannot* assume that *only* the index has been affected. The runtime cannot simply assume the index being out of bounds is not the result of already occurred data corruption, because that is inherently unsafe, so it *must* terminate asap as the default.

If you get the index as the input to your process - and thus *know* that it being out of bounds is not the result of previous data corruption - then you should check this yourself before accessing the array and handle it appropriately (e.g. via Exception).

So in your specific use case I would say use a wrapper. This is one of the reasons why I am working on my own library for data structures (libds).

On Wednesday, 31 May 2017 at 13:04:52 UTC, Steven Schveighoffer wrote:
> This is like the  equivalent of having a guard rail on a road not only stop you from going off the cliff but proactively disable your car afterwards to prevent you from more harm.

Sorry for double post, but - after thinking more about this - I do not agree that this fits. I think a better analogy would be this:
Your car has an autonomous driving system and an anti-collision system and the anti-collision system detects that you are about to hit an obstacle (let us say another car); as a result it engages the breaks and shuts off the autonomous driving system.
It might be that the autonomous driving system was in the right and the reason for the almost collision was another human driver driving illegally, but it might also be that there is a bug in the autonomous driving system. If the latter is the case, in this one instance the anti-collision device detected the result of the bug, but the next time it might be that the autonomous driving system drives you off a cliff, which the anti-collision would not help against.
So the only sane thing to do is shut the autonomous driving system off, requiring human intervention to decide which of the two was the case (and if it was the former, turn it on again).

On 05/31/2017 02:55 PM, Moritz Maxeiner wrote:
> On Wednesday, 31 May 2017 at 17:13:08 UTC, Nick Sabalausky (Abscissa) wrote:
>> On 05/31/2017 09:04 AM, Steven Schveighoffer wrote:
>>>
>>> What are your thoughts?
>>
>> +1 million. I *hate* D's notion of Error. Well, no...more correctly, I absolutely hate that it throws cleanup/unwinding straight out the window for many situations that can obviously be handled safely without the paranoid "ZOMG Sky Is Falling!!!!" overreaction that is baked into the design of Error. And that causes problems like the one you describe.
> 
> To be fair, anything that can be handled in a sane&safe way should inherit from Exception, not from Error, so throwing away cleanup for Error makes sense, since an Error means the program is in an undefined state and should terminate asap.

Then out-of-bounds and assert failures should be Exception not Error. Frankly, even out-of-memory, arguably. And then there's null dereference... In other words, basically everything.

On 05/31/2017 03:17 PM, Moritz Maxeiner wrote:
> in general you have to assume that the index *being* out of bounds is itself the *result* of *already occurred* data corruption;
Of course not, that's absurd. Where do people get the idea that out-of-bounds *implies* pre-existing data corruption? Most of the time, out-of-bounds comes from a bug (especially in D, what with all of its safeguards).

Sure, data corruption is one possible cause of out-of-bounds, but data corruption is one possible cause of *ANYTHING*. So just to be safe, let's just abort on all exceptions, and upon everything else for that matter.

On Wednesday, 31 May 2017 at 20:09:16 UTC, Nick Sabalausky (Abscissa) wrote:
> [...]
>> program is in an undefined state and should terminate asap.
>
> Then out-of-bounds and assert failures should be Exception not Error. Frankly, even out-of-memory, arguably. And then there's null dereference... In other words, basically everything.

No, because as I stated in my other post, the runtime *cannot* assume that it is safe *in all cases*. If there is even one single case in which it is unsafe, it must abort.

On Wednesday, 31 May 2017 at 13:04:52 UTC, Steven Schveighoffer wrote:
> This seems like a large penalty for "almost" corrupting memory. No other web framework I've used crashes the entire web server for such a simple programming error.

On windows you can set up service restart settings in case it crashes. Useful for services that crash regularly.

On 5/31/17 3:17 PM, Moritz Maxeiner wrote:
> On Wednesday, 31 May 2017 at 13:04:52 UTC, Steven Schveighoffer wrote:
>> [...]
>>
>> What are your thoughts? Have you run into this? If so, how did you
>> solve it?
>>
>
> It is not that accessing the array out of bounds *leading* to data
> corruption that is the issue here, but that in general you have to
> assume that the index *being* out of bounds is itself the *result* of
> *already occurred* data corruption;

To be blunt, no this is completely wrong. Memory corruption *already having happened* can cause any number of errors. The point of bounds checking is to prevent memory corruption in the first place. I could memory corrupt the length of the array also (assuming a dynamic array), and bounds checking merrily does nothing to stop further memory corruption.

> and if data corruption occurred for
> the index, you *cannot* assume that *only* the index has been affected.
> The runtime cannot simply assume the index being out of bounds is not
> the result of already occurred data corruption, because that is
> inherently unsafe, so it *must* terminate asap as the default.

The runtime should not assume that crashing the whole program is necessary when an integer is out of range. Preventing actual corruption, yes that is good. But an Exception would have done the job just fine.

But that ship, as I said elsewhere, has sailed. We can't change it to Exception now, as that would break just about all nothrow code in existence.

> So in your specific use case I would say use a wrapper. This is one of
> the reasons why I am working on my own library for data structures (libds).

That is my conclusion too. Is your library in a usable state? Perhaps we should not repeat efforts, though I wasn't planning on making a robust public library for it :)

-Steve

On 5/31/17 4:06 PM, Moritz Maxeiner wrote:
> On Wednesday, 31 May 2017 at 13:04:52 UTC, Steven Schveighoffer wrote:
>> This is like the  equivalent of having a guard rail on a road not only
>> stop you from going off the cliff but proactively disable your car
>> afterwards to prevent you from more harm.
>
> Sorry for double post, but - after thinking more about this - I do not
> agree that this fits. I think a better analogy would be this:
> Your car has an autonomous driving system and an anti-collision system
> and the anti-collision system detects that you are about to hit an
> obstacle (let us say another car); as a result it engages the breaks and
> shuts off the autonomous driving system.

Nope, an autonomous system did not type out my code that caused the out of bounds error, I did :)

-Steve