>
> For example when I’m writing a throw-away script, some notices are okay to
> indicate possible problems
Maybe it's just me, but even in throw-away scripts, *I've lost much more
time because of warnings/notices going unnoticed, than I've saved thanks to
PHP's forgiving nature*.
Hence even in the shittiest of my scripts, I usually end up registering an
error handler to throw an exception even for the smallest notice. At least,
I always get an exception right in my face when something's unexpected, so
I can fix it and move on, and avoid surprises later on.
Sure, in a quick script, I do see some value in being able to write stuff
like:
@ $array['non_existing_key']++;
It's still sloppy though: what you're really doing is muting a notice and
incrementing null.
Instead, I feel like there should be a stronger support from the language
to specifically handle this kind of use cases, rather than using them as a
justification for not *severely *hardening error reporting.
I don't think there are that many such *potentially *legitimate use cases,
so maybe we could just list the use cases and think about a more elegant
solution to solve them?
In other words, if that was only me, the whole notice/warning stuff would
go, and PHP would only have exceptions.
Undefined variables would throw, undefined array keys would throw, and use
cases like the above would have stronger language support to avoid
boilerplate code full of if(isset()).
— Benjamin
On Thu, 12 Sep 2019 at 11:42, Claude Pache <claude.pa...@gmail.com> wrote:
>
>
> > Le 12 sept. 2019 à 10:17, Stephen Reay <php-li...@koalephant.com> a
> écrit :
> >
> >
> >
> > I’ve seen a number of people that have concerns about PHP throwing
> actual errors (as opposed to notices) because they try to use a
> variable/offset that doesn’t exist, and of course there is often a proposal
> to have a declare statement or something similar, to allow their “code
> style” to run without errors.
> >
> >
> > So, my proposal to the situation is to introduce a single declare that
> solves that problem, once and for all.
> >
> >
> > declare(sloppy=1);
> >
> >
> > This would suppress any errors about undefined variables, array offsets,
> would reverse the “bare words" change when encountering an undefined
> constant, etc. Heck, for good measure this mode could even re-implement
> register_globals and magic_quotes, because why not?
> >
> >
> >
> > If you want to write sloppy code, that is entirely your prerogative, but
> please just own it for what it is, and stop pretending that it’s some
> herculean task to either define variables/offsets first; or check if
> they’re defined; or use an appropriate method to access them that
> specifically allows for undefined variables/offsets (i.e. the ?? and ??=
> operators)
> >
> >
>
> Declare(sloppy=yeah) is not granular enough. To all: please, do understand
> that everything is not black or white; this remark is not directed
> specifically to that particular issue, this is an attitude I see regularly
> on that mailing list.
>
> There is no such thing as “one true strict coding standard” and “one
> legacy lax coding standard”. For instance:
>
> * As time passes, we learn by experience what features were plain blunders
> (magic_quotes?), what features should have been more strict for the sake of
> catching bugs without imposing too much burden on users, what features
> could have been more strict, although that would impose to write lot of
> boiler code, etc. This process does not belong exclusively to some past
> dark age of sloppy and unsecure coding practices.
>
> * The degree of wanted strictness vary depending on occasions. For example
> when I’m writing a throw-away script, some notices are okay to indicate
> possible problems, but I’m not going to write boilerplate code (or, worse,
> put a @ in front of everything) just for the sake of silencing them. (But I
> *certainly* do not want stupid things like mistyped constants converted to
> string literals.) On the other hand, when I’m writing a critical part of an
> application, I am careful to write down everything precisely, and having to
> write explicitly and once for all that, yes, this precise variable must
> have that default value, is a minimal part of the time passed to write,
> re-read and review the code.
>
> —Claude
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
