Re: [RFC] Change checkdnsrr() $type argument behavior

I checked and it looks like E_WARNING is what we currently throw for that. Should we consider changing that to E_ERROR? I mean, if a function *requires* an argument that's missing, I don't think we'd want that script execution to continue. What's the reasoning behind the current behavior of just throwing a warning on broken function calls like this? Are we just mimicking behavior in other languages or something? I'm sorry if this is a stupid question, but I honestly can't figure out why it's preferable to only throw a warning on these. --Kris On Fri, Sep 19, 2014 at 11:05 PM, Kris Craig <kris.craig@gmail.com> wrote: > > On Sep 19, 2014 10:50 PM, "Michael Wallner" <mike@php.net> wrote: > > > > > > On 20 Sep 2014 04:15, "Kris Craig" <kris.craig@gmail.com> wrote: > > > > > > > > > > > From what I can tell, there are valid arguments to be made for both, > so I > > > would love to see some discussion/debate here regarding which solution > > > should be implemented, as I'm currently undecided. Also please feel > free > > > to point out any areas of improvement for the RFC itself. > > > > > > > Functions don't throw E_ERROR on missing argument. > > > > And ANY is about as bad as MX. > > I can fix that. What would be the customary one to throw for a missing > arg? > > --Kris >