Finer control of diagnostics (deprecations, notices, and warnings)

  116363
November 15, 2021 11:34 rowan.collins@gmail.com (Rowan Tommins)
Hi all,

Concerns have been raised a few times recently about adding new warnings 
and deprecation notices, particularly:

* That code bases with many instances of a particular pattern see a lot 
of noise when a message is added
* That library maintainers face pressure to fix deprecations from users 
who don't want to see those messages in their logs

I don't think "stop adding new diagnostics to PHP" is a good solution to 
these problems, and have thought of two ideas which might improve 
things; both need refinement, but I hope can at least act as discussion 
starters.


The first idea is directory-level error_reporting configuration.

In principle, this would be very simple: a mechanism (ini setting or 
function) that lets a user specify a different error_reporting level for 
all code compiled from a particular directory. The most common use I 
foresee is reducing reporting in third-party libraries, e.g.

error_reporting=E_ALL
error_reporting[*/vendor/*]=E_ERROR+E_WARNING

This would hopefully reduce pressure on maintainers to fix deprecation 
notices as soon as they appear, because they would no longer be 
cluttering the user's logs.


The second idea is diagnostic codes or categories.

This is more complicated, because it requires classifying all existing 
diagnostics to add extra information, but would allow users to act 
differently on specific messages. They might suppress them, downgrade 
Warnings to Notices, or even upgrade Notices to Warnings - as they might 
with rules in an IDE or Static Analysis tool.

As an extension, the @ operator could be enhanced to suppress a specific 
diagnostic, so that the following would give an "undefined variable" 
warning, but be silent about the file not existing:

@{FILE_NOT_FOUND}fopen($undefinedVariable, 'r');


Regards,

-- 
Rowan Tommins
[IMSoP]
  116364
November 15, 2021 12:03 michal.brzuchalski@gmail.com (=?UTF-8?Q?Micha=C5=82_Marcin_Brzuchalski?=)
Hi Rowan,

pon., 15 lis 2021 o 12:34 Rowan Tommins collins@gmail.com>
napisał(a):

> Hi all, > > Concerns have been raised a few times recently about adding new warnings > and deprecation notices, particularly: > > * That code bases with many instances of a particular pattern see a lot > of noise when a message is added > * That library maintainers face pressure to fix deprecations from users > who don't want to see those messages in their logs > > I don't think "stop adding new diagnostics to PHP" is a good solution to > these problems, and have thought of two ideas which might improve > things; both need refinement, but I hope can at least act as discussion > starters. > > > The first idea is directory-level error_reporting configuration. > > In principle, this would be very simple: a mechanism (ini setting or > function) that lets a user specify a different error_reporting level for > all code compiled from a particular directory. The most common use I > foresee is reducing reporting in third-party libraries, e.g. > > error_reporting=E_ALL > error_reporting[*/vendor/*]=E_ERROR+E_WARNING >
IMO this screams for comments regarding modules/packages/assemblies however called where error_reporting could be controlled by vendors. Personally, I think that given feature users would add whole vendor directory, since the vendor/package directory is not fixed, may change - which in essence may go out of control and silently invoke a waterfall of unexpected errors.
> This would hopefully reduce pressure on maintainers to fix deprecation > notices as soon as they appear, because they would no longer be > cluttering the user's logs. > > > The second idea is diagnostic codes or categories. > > This is more complicated, because it requires classifying all existing > diagnostics to add extra information, but would allow users to act > differently on specific messages. They might suppress them, downgrade > Warnings to Notices, or even upgrade Notices to Warnings - as they might > with rules in an IDE or Static Analysis tool. > > As an extension, the @ operator could be enhanced to suppress a specific > diagnostic, so that the following would give an "undefined variable" > warning, but be silent about the file not existing: > > @{FILE_NOT_FOUND}fopen($undefinedVariable, 'r'); >
This proposal allows to silence errors in certain statements but instead of extending silence operator personally, I'd prefer to enable statement-level attributes and shape them in an opt-in manner. Instead of proposing new syntax backward incompatible like this: $fp = @{FILE_NOT_FOUND}fopen($undefinedVariable, 'r'); introduce statement level attributes which can be backward compatible when in one line $fp = #[SupressErrors(E_WARNING)] fopen($undefinedVariable, 'r'); What do you think? Cheers, Michał Marcin Brzuchalski
  116365
November 15, 2021 12:06 michal.brzuchalski@gmail.com (=?UTF-8?Q?Micha=C5=82_Marcin_Brzuchalski?=)
pon., 15 lis 2021 o 13:03 Michał Marcin Brzuchalski <
michal.brzuchalski@gmail.com> napisał(a):

> Hi Rowan, > > pon., 15 lis 2021 o 12:34 Rowan Tommins collins@gmail.com> > napisał(a): > >> Hi all, >> >> Concerns have been raised a few times recently about adding new warnings >> and deprecation notices, particularly: >> >> * That code bases with many instances of a particular pattern see a lot >> of noise when a message is added >> * That library maintainers face pressure to fix deprecations from users >> who don't want to see those messages in their logs >> >> I don't think "stop adding new diagnostics to PHP" is a good solution to >> these problems, and have thought of two ideas which might improve >> things; both need refinement, but I hope can at least act as discussion >> starters. >> >> >> The first idea is directory-level error_reporting configuration. >> >> In principle, this would be very simple: a mechanism (ini setting or >> function) that lets a user specify a different error_reporting level for >> all code compiled from a particular directory. The most common use I >> foresee is reducing reporting in third-party libraries, e.g. >> >> error_reporting=E_ALL >> error_reporting[*/vendor/*]=E_ERROR+E_WARNING >> > > IMO this screams for comments regarding > modules/packages/assemblies however called > where error_reporting could be controlled by vendors. > Personally, I think that given feature users would add whole vendor > directory, > since the vendor/package directory is not fixed, > may change - which in essence may go out of control and silently invoke a > waterfall of unexpected errors. > > >> This would hopefully reduce pressure on maintainers to fix deprecation >> notices as soon as they appear, because they would no longer be >> cluttering the user's logs. >> >> >> The second idea is diagnostic codes or categories. >> >> This is more complicated, because it requires classifying all existing >> diagnostics to add extra information, but would allow users to act >> differently on specific messages. They might suppress them, downgrade >> Warnings to Notices, or even upgrade Notices to Warnings - as they might >> with rules in an IDE or Static Analysis tool. >> >> As an extension, the @ operator could be enhanced to suppress a specific >> diagnostic, so that the following would give an "undefined variable" >> warning, but be silent about the file not existing: >> >> @{FILE_NOT_FOUND}fopen($undefinedVariable, 'r'); >> > > This proposal allows to silence errors in certain statements but instead > of extending silence operator > personally, I'd prefer to enable statement-level attributes and shape them > in an opt-in manner. > Instead of proposing new syntax backward incompatible like this: > > $fp = @{FILE_NOT_FOUND}fopen($undefinedVariable, 'r'); > > introduce statement level attributes which can be backward compatible when > in one line > > $fp = > #[SupressErrors(E_WARNING)] > fopen($undefinedVariable, 'r'); >
My apologies this won't work for 8.0 and 8.1 since there are no statement-level attributes and the online attribute as a comment hack works only for <8.0 versions. Regards,
  116368
November 15, 2021 13:17 rowan.collins@gmail.com (Rowan Tommins)
On 15/11/2021 12:03, Michał Marcin Brzuchalski wrote:
> Personally, I think that given feature users would add whole vendor > directory, > since the vendor/package directory is not fixed, > may change - which in essence may go out of control and silently > invoke a waterfall of unexpected errors.
I don't understand your concern; possibly you have misunderstood my suggestion? I'm saying that a user who wants to see if they are using deprecated features in their own code would want to turn on E_DEPRECATED in their main error_reporting, but turn it OFF for all third-party code. Most of the time, deprecation notices in third-party code are not useful to users: they are not responsible for fixing them in advance, and when actually switching major PHP version, they may have to switch to a different major release of the library before testing anyway. Regards, -- Rowan Tommins [IMSoP]