Re: Adding validate_var_array()/validate_input_array() to which version?
| From: | Pierre Joye | Date: | Sun, 07 Aug 2016 12:20:56 +0000 |
| Subject: | Re: Adding validate_var_array()/validate_input_array() to which version? | ||
| References: | 1 2 3 4 5 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-94899@lists.php.net to get a copy of this message | ||
On Aug 5, 2016 2:30 AM, "Yasuo Ohgaki" <yohgaki@ohgaki.net> wrote:
>
> Hi Christian,
>
> On Thu, Aug 4, 2016 at 8:27 PM, Christian Stadler <stadli@gmx.de> wrote:
> > Am 04.08.2016 um 12:10 schrieb Yasuo Ohgaki:
> >> Hi Christian and all,
> >>
> >> On Thu, Aug 4, 2016 at 10:07 AM, Christian Stadler <stadli@gmx.de>
wrote:
> >>> Am 01.08.2016 um 10:23 schrieb Yasuo Ohgaki:
> >>>> P.S. It's possible to return array that contains offending values. It
> >>>> is not included since users can store whole offending input array.
> >>>> Whole input is more useful for attack analysis.
> >>> Actually I wanted to suggest exactly that for ppl. who want to give
> >>> Feedback to their users, what values failed to validate to the users.
> >>> Probably with a fourth optional param, like
$return_invalid =
> >>> false?
> >>> Of course logging is a different topic and should always use the whole
> >>> offending input array.
> >> I can set offending value to filter globals so that it can be
> >> retrieved later in catch block. I cannot return or modify referenced
> >> parameter because of raised exception.
> >
> > Well, since some people have objections about raising exceptions here,
> > this should probably be either in a seperate vote or additional options
> > in the main vote. Probably something, like:
> > Yes, either | Yes, without the exception | Yes, with the exception | No
> > Personally I would vote for 'Yes, either'. If I could, that is.
>
> One of my objective is following best practices.
> Prefer exception over error is one of them. Although, I strongly suggest
> to use exception for validation errors, I will have choices.
I see them as conditions flow not errors per se but flow.
Invalid options could raise exceptions but it brings inconcistencies with
the other filter functions.
I feel like this rfc needs more discussions and maybe we will add more
things to filter as well.
But anything proposed is already possible very easily in userland. I would
not rush it into 7.1.