On Saturday, 3 June 2017 at 10:47:36 UTC, Ola Fosheim Grøstad
wrote:
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.
Sorry Ola, I can't support that way of working.
Don't take it wrong, Walter is doing a lot on @safe, but
compilers are built from a codebase, and the codebase has,
anyway, bugs.
I can't approve a "ok, do whatever you want in the validate_input
and I try to *safely* throw"
IMHO you can only do that if the validator is totally segregated,
and to me that means in a separate process, neither in another
thread.
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.
To me, pragmatic means that the B2B website has to be organised
in a way that the impact is minimum if one of the processes that
are handling the requests are restarted, for a bug or not. See
Laeeth [1]. Just handle "insignificant requests" to a cheeper,
less robust, less costly, web stack.
But we were talking about another argument...
/Paolo
[1]
http://forum.dlang.org/post/uvhlxtolghfydydox...@forum.dlang.org
