Bad array indexing is considered deadly

[Steven Schveighoffer via Digitalmars-d]

On 5/31/17 9:21 AM, H. S. Teoh via Digitalmars-d wrote:
> On Wed, May 31, 2017 at 09:04:52AM -0400, Steven Schveighoffer via Digitalmars-d wrote:
>> I have discovered an annoyance in using vibe.d instead of another web
>> framework. Simple errors in indexing crash the entire application.
>>
>> For example:
>>
>> int[3] arr;
>> arr[3] = 5;
>>
>> Compare this to, let's say, a malformed unicode string (exception),
>> malformed JSON data (exception), file not found (exception), etc.
>>
>> Technically this is a programming error, and a bug. But memory hasn't
>> actually been corrupted. The system properly stopped me from
>> corrupting memory. But my reward is that even though this fiber threw
>> an Error, and I get an error message in the log showing me the bug,
>> the web server itself is now out of commission. No other pages can be
>> served. 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.
> [...]
>
> Isn't it customary to have the webserver launched by a script that
> restarts it whenever it crashes (after logging a message in an emergency
> logfile)?  Not an ideal solution, I know, but at least it minimizes
> downtime.

Yes, I can likely do this. This kills any existing connections being 
handled though, and is far far from ideal. It's also a hard crash, any 
operations such as writing DB data are killed mid-stream.

But you won't win over any minds that are used to php or python with 
this workaround.

>
> On another note, why didn't the compiler reject the above code? I
> thought it checks static arrays bounds at compile time whenever
> possible. Did I remember wrong?

I'm not sure, it's a toy example. In the real bug, the index was a 
variable. The annoying thing about this is that there is no actual 
memory corruption. It was properly stopped.

-Steve