Bad array indexing is considered deadly

[Ola Fosheim Grøstad via Digitalmars-d]

On Thursday, 1 June 2017 at 05:03:17 UTC, Jonathan M Davis wrote:
> Whether memory corruption is involved is irrelevant. The 
> program violated the contract, so the runtime knows that the 
> program is in an invalid state. The cause of that bug may or 
> may not be localized, but it's a guarantee at that point that 
> the program is wrong, so you can't rely on it doing the right 
> thing.

Well, if you take this position then you should not only crash 
the program, but also delete the executable to prevent it from 
being run again.

Allowing the process to be restarted when you know that it 
contains logic errors breaks with the principles you are 
outlining.

> handle that case appropriately. For the vast majority of 
> programs, most array indices do not come from user input, and 
> thus it usually really doesn't make sense to treat passing an 
> invalid index to an array as anything other than a bug. It's 
> reasonable to expect the programmer to get it right and that if 
> they don't, they'll find it during testing.

It is surprisingly common to forget to check for a field/file 
being empty in a service. So it makes a lot of sense to roll back 
for such errors and keep the service alive. In my experience this 
is the common scenario. And indexing an array is no different 
than asking for a key that doesn't exist in any other 
data-structure, array shouldn't be a special case. Does that mean 
that other ADTs also should throw Error and not Exception?

For instance, assume you have a chat-server and the supplied 
clients work fine. Then some guy decides to reverse engineer it 
and build his own client. You don't want that service to go down 
all the time. You want to shut out that specific client. You want 
to identify the client and block it.