Hi! > It seems there is misunderstanding. > These new functions are intended for "secure coding input validation" that > should never fail. It means something unexpected in input data that > cannot/shouldn't keep program running. Why do you need to parse > message?
I think the problem here is as follows: assume you accept use input. You want it to conform to some set of rules. If it does not, you may want to inform the user that the input is wrong, in an informative way. Now, if you say these functions "should never fail", it implies that before them, there would be other functions filtering user input (because user input could always violate whatever rules you'd have) - and then the question is, would you really want *two* sets of validators? You'd probably want one. Now, when you have one, you probably want it to validate the data and return some information that would be useful for informing the user what has gone wrong. That seems to be the issue here. I do think having strong input validation is a good thing. However, we'd also need to have them in a way that would make them useful in above scenario - otherwise people would avoid them because they fail "too hard" and the app does not retain enough control over the outcome. > There is misunderstanding on this. > As I wrote explicitly in the RFC, input validation and user input > mistakes must be handled differently. > > "The input validation (or think it as assertion or requirement) error" > that this RFC is dealing, is should never happen conditions (or think > it as contract should never fail). This is what I'm not sure I understand - when this approach would be used? I.e. if I get data from the user, I surely can not claim I can impose any conditions on the data that would never fail. Is it assumed I'd pre-filter the data before passing it to this filter? > The point of having the input validation is accept only inputs that > program expects and can work correctly. Accepting unexpected > data that program cannot work correctly is pointless. Well, that depends on what you mean by "accepting". The program should exhibit sane behavior (i.e., useful error message, not whitescreen or something like that) on bad input. That behavior can be different - i.e., if you are given wrong password, you shouldn't be too helpful and say "this password is wrong, the right password is this: ...." (you'd laugh but there *was* a real application doing this, no, I have no idea what the developers were thinking :) but at least you could say "authentication details are wrong". > Don't misunderstood me. I'm not saying "You should reject user input > mistakes". > "User input mistakes" and "input validation error" is totally different > error. Here, again, I am not sure I understand the difference. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
