Bad array indexing is considered deadly

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 05/31/2017 10:39 PM, Jonathan M Davis via Digitalmars-d wrote:
> On Wednesday, May 31, 2017 22:24:16 Nick Sabalausky  via Digitalmars-d
> wrote:
>> On 05/31/2017 05:00 PM, Steven Schveighoffer wrote:
>>> 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.
>>
>> This is why the runtime needs to guarantee that normal unwinding/cleanup
>> *does* occur on Error (barring actual corruption or physical
>> impossibilities, obviously).
> 
> It is my understanding that with how nothrow is implemented, that's not
> actually possible. The compiler takes advantage of nothrow to optimize out
> the exception handling code where possible. To force it to stay just to try
> and clean up when an Error is thrown would defeat the performance gains that
> we get with nothrow.
> 
> Besides, it's highly debatable that you're actually better off cleaning up
> when an Error is thrown, because it largely depends on what has gone wrong.
> In some cases, it _would_ be better if clean-up occurred, whereas in others,
> it's just making matters worse.
> 
> What we currently have is a weird hybrid. When an Error is thrown, _some_ of
> the clean-up is done, but not all. Whether that's worse than doing no
> clean-up is debatable, but regardless, due to nothrow, we can't do all of
> the clean-up, so relying on all of the clean-up occurring is error-prone.
> And pretty much the only reason that _any_ clean-up is done when an Error is
> thrown is because someone implemented it when Walter wasn't looking.
> 
> The reality of the matter though is that no matter what we do, a completely
> robust program must be able to deal with the fact that it could be killed at
> any time (e.g. due to a power outage) - not that it needs to function
> perfectly when it gets killed, but for stuff like database consistency, you
> can't rely on the program dying gracefully to avoid data corruption.
> 
> - Jonathan M Davis
>