Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106938
MIME-Version: 1.0
References: <CAF+90c9Kc6m_bv=aJxbD3-RmnNXXLqv6mPjHp7U7qxX_ck27qw@mail.gmail.com>
 <CAF+90c_KHYm1SLOKkZXM6xurYiDTX3=hbijpD8rT1OSUHSod_w@mail.gmail.com>
 <CEC35EF9-9956-44BE-8C8E-EE5FC3D5A7C7@gmail.com> <D5DDA318-E953-4AB8-873F-7CA7264722E2@koalephant.com>
 <E30D9A22-9842-4A67-ABA5-A339875FFE12@gmail.com> <CAG9XoMTG3OLbD0BfWv+ORUUsbMV2CaF0Ea4NLF1huHBr5JCmWQ@mail.gmail.com>
In-Reply-To: <CAG9XoMTG3OLbD0BfWv+ORUUsbMV2CaF0Ea4NLF1huHBr5JCmWQ@mail.gmail.com>
Date: Thu, 12 Sep 2019 13:32:00 +0200
Message-ID: <CAL0xaBFdA0hi1Y1ESBFO8-oQQ5Q=S7qk2=LUk6h9LcawSODUdw@mail.gmail.com>
To: Benjamin Morel <benjamin.morel@gmail.com>
Cc: Claude Pache <claude.pache@gmail.com>, Stephen Reay <php-lists@koalephant.com>, 
	Nikita Popov <nikita.ppv@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000fcb0f00592597d83"
Subject: Re: [PHP-DEV] [RFC] Reclassifying engine warnings
From: arvids.godjuks@gmail.com (Arvids Godjuks)

--000000000000fcb0f00592597d83
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=D1=87=D1=82, 12 =D1=81=D0=B5=D0=BD=D1=82. 2019 =D0=B3. =D0=B2 12:32, Benja=
min Morel <benjamin.morel@gmail.com>:

> >
> > For example when I=E2=80=99m 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 a=
n
> error handler to throw an exception even for the smallest notice. At leas=
t,
> I always get an exception right in my face when something's unexpected, s=
o
> 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 us=
e
> cases like the above would have stronger language support to avoid
> boilerplate code full of if(isset()).
>
> =E2=80=94 Benjamin
>

Every single workplace I worked in past 5 years always had 0 tolerance
policy for all notices, warnings and E_STRICT.
Since I started PHP in 2005, I have always worked with a 0
warning/notice/strict tolerance policy, in every workplace I have ever
worked. All those were fixed as bugs, heck even management pointed out
those from logging aggregation and made bugs to be fixed.
At this point, if I see that the company does not do this, I skip it.
Usually, it is a sign of way more stuff being wrong, but this alone is
already enough to have reservations about the advertised position.

The world has moved on how software is developed since the early 2000's
when this was okay. These days, at least in my dev circle, it is not okay
to have notices/warnings in your code.

--000000000000fcb0f00592597d83--