Bad array indexing is considered deadly

[Ola Fosheim Grøstad via Digitalmars-d]

On Wednesday, 31 May 2017 at 21:57:04 UTC, Ali Çehreli wrote:
> of bounds but it's one special case. The actual reason for 
> bounds checking is maintaining an invariant.

That's true, but that could be the case with file system 
exception too. Say, a file is supposed to be of length N, but you 
get an exception because you are reading past the file end. Same 
issue.

Should you then wipe the entire file system, because there 
appears to be a problem with a single file?

> In the case of array indexes, they are in complete control of 
> the program, hence a bug when out of bounds. It's not possible 
> to say "Bad index; let me try 42 less."

Well, it is possible that the bad indexing was because the input 
was empty and there was a mistake in the program.

One reasonable thing to do is to rollback for that particular 
input, log it as a problem, then continue processing other input.

Which is often better than shutting down the service, but it 
really is contextual.

The real question is, what is the probability of a mismatched 
index for your application being just an indexing problem. I 
think it is very high for most "safe" code.

So if D supports "safe" code well, then indexing issues will most 
likely almost never be due to corruption.

If you only write "unsafe" code, then indexing issues are still 
most likely to not be because of corruption, but the probability 
is much higher.