# Finer control of diagnostics (deprecations, notices, and warnings) - Thread: https://externals.io/message/116363 - Original archive: https://news-web.php.net/php.internals/116363 - Started by Rowan Tommins on 2021-11-15T11:34:09+00:00 - Messages: 4 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #116363 — Rowan Tommins — 2021-11-15T11:34:09+00:00 URL: https://externals.io/message/116363#116363 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 — michal.brzuchalski@gmail.com — 2021-11-15T12:03:28+00:00 URL: https://externals.io/message/116363#116364 · In reply to: #116363 Hi Rowan, pon., 15 lis 2021 o 12:34 Rowan Tommins 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 — michal.brzuchalski@gmail.com — 2021-11-15T12:06:28+00:00 URL: https://externals.io/message/116363#116365 · In reply to: #116364 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 > napisał(a): > > > […] > > 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 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 — Rowan Tommins — 2021-11-15T13:17:55+00:00 URL: https://externals.io/message/116363#116368 · In reply to: #116364 > 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]