Problem/Motivation

Error handler _drupal_error_handler_real() using list($severity_msg, $severity_level) = $types[$error_level]; to get mapping of error levels, but for level that are not in drupal_error_levels() it throws notice

Proposed resolution

Add isset() for checking to get rid of Notice: Undefined offset

Remaining tasks

accept, commit

User interface changes

API changes

Data model changes

CommentFileSizeAuthor
#14 core-2940136-14.patch1.29 KBjoshahubbers
#2 2940136-2.patch1.53 KBandypost

Comments

andypost created an issue. See original summary.

andypost’s picture

andypost
he/him
Primary language Russian
commented
Status: Active » Needs review
StatusFileSize
new 2940136-2.patch1.53 KB
borisson_’s picture

borisson_
Primary language Dutch
Location Mechelen, 🇧🇪
commented

I'm not sure we should do this, instead of throwing the notice, we could also thrown an exception.

andypost’s picture

andypost
he/him
Primary language Russian
commented

@borisson_ but this is the exception handler itself, that's why I think "masking" missing error mapping is enough, we can't predict what will came in

andypost’s picture

andypost
he/him
Primary language Russian
commented

Actually the job of the function is to populate proper backtrace so own notices makes it corrupted

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

voleger’s picture

voleger
he/his
Primary language Ukrainian
Location Ukraine, Rivne
commented
Related issues: +#3000229: Add DrupalErrorHandler wrapping Symfony ErrorHandler component

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

joshahubbers’s picture

joshahubbers commented
StatusFileSize
new core-2940136-14.patch1.29 KB

I think the patch makes sense. You still add the right backtrace, you just add a notion that the error level supplied is not recognized.

This patch is modified to clarify that the error level is not recognized and fixed for 9.3.x

But this is also fixed in #3000229: Move error handlers to an Error class

joshahubbers’s picture

joshahubbers commented
Status: Needs review » Closed (duplicate)

After another review, I suggest to close this one in favor of #3000229: Move error handlers to an Error class, to avoid duplicate issues.
This issue is fully addressed there, and that issue is much more a generic way to go.

On the other hand: the patch can be applied cleanly, and is a quick-fix improvement of the code imho, so if someone thinks this should be committed until the other issue is resolved, I can support that also.

joshahubbers’s picture

joshahubbers commented
Issue tags: +Bug Smash Initiative