On Sun, Aug 7, 2016 at 8:20 AM, Niklas Keller <m...@kelunik.com> wrote:
> 2016-08-07 14:20 GMT+02:00 Pierre Joye <pierre....@gmail.com>: > > > On Aug 5, 2016 2:30 AM, "Yasuo Ohgaki" <yohg...@ohgaki.net> wrote: > > > > > > Hi Christian, > > > > > > On Thu, Aug 4, 2016 at 8:27 PM, Christian Stadler <sta...@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 <sta...@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. > > > > Isn't it a bit late to target 7.1 anyway? > Yes, it is much too late for 7.1, this will have to be targeted towards 7.2+ - Davey
