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

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 rowan.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,

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]