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.
