Bad array indexing is considered deadly

Ola Fosheim Grøstad via Digitalmars-d digitalmars-d at puremagic.com
Sat Jun 3 03:47:36 PDT 2017


On Saturday, 3 June 2017 at 10:21:03 UTC, Paolo Invernizzi wrote:
> It doesn't seems to me that the trends to try to handle 
> somehow, that something, somewhere, who knows when, has gone 
> wild it's coherent with the term "robustness".

That all depends. It makes perfect sense in a "strongly pure" 
function to just return an exception for basically anything that 
went wrong in that function.

I use this strategy in other languages for writing 
validator_functions, it is a very useful and time-saving way of 
writing validators. E.g.:

try {
     …
     validated_field = validate_input(unvalidated_input);
}

I don't really care why validate_input failed, even if it was a 
logic flaws in the "validate_input" code itself it is perfectly 
fine to just respond to the exception, log the failure return a 
failure status code and continue with the next request.

The idea that programs can do provably full veracity checking of 
input isn't realistic in evolving code bases that need constant 
updates.

My "validate_input" only have to be correct for correct input. If 
it fails because the input is wrong or because the validation 
spec is wrong does not matter, as long as it fails.

> And the fact that the "nice tries" are done at runtime, in 
> production, is the opposite of what I'm thinking is program 
> verification.

Program verification requires a spec.

In the above example the spec could be that it should never allow 
illegal input to pass, but it could also make room for failing 
for some legal input.

"false alarm" is a concept that is allowed for in many real world 
application.

In this context it means that you throw too many exceptions, but 
that does not mean that you don't throw an exception when you 
should have.

> I'm trying to exactly do that, I like to think myself as a very 
> pragmatic person...

What do you mean by "pragmatic"? Shutting down a B2B website 
because one insignificant request-handler fails on some requests 
(e.g. requesting a help page)  is not very pragmatic.

Pragmatic in this context would be to specify which handlers are 
critical and which ones are not.



More information about the Digitalmars-d mailing list