On Fri, Dec 4, 2020 at 9:33 AM Claude Pache <claude.pa...@gmail.com> wrote:
> > > > Le 3 déc. 2020 à 22:05, Levi Morrison <levi.morri...@datadoghq.com> a > écrit : > > > > This is a long-standing behavior. Further, I don't know many people > > who want _more_ warnings in their codebase. > > > My guess is that this position was already discussed in the occasion of > the several past RFC whose main purpose was to introduce more > warnings/errors/exceptions? [1], [2], [3], etc. Apparently, many people do > want more warnings... > This is getting a bit off-topic, but I think it's necessary to clarify: What many of us actually want is *less* warnings. Having less warnings can take the form of converting them to exceptions, or take the form of removing them entirely. Both of these things happen, but the conversions to exceptions tend to be the more controversial and thus take the spotlight. I'm personally not a fan of warnings thrown by stream/FS functions (especially when backed by socket streams), as robust code just ends up having to suppress them all. Unfortunately I can't say that these warnings are entirely useless, as they *are* helpful for debugging. It would be nice if PHP had a stronger separation between "this is an error" warnings and "this is informational" warnings. Things are slowly moving in this direction with the first category being partially converted into exceptions... But well, that's a global problem. The current stance of stream/FS functions is very much that all error conditions should warn. Regards, Nikita
