Problem/Motivation

Follow-up to #2521852: Make it possible to use your own exception handler

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

CommentFileSizeAuthor
#5 constructor-arguments-mismatch-before-2509898.png33.79 KBznerol
#5 break-entity-form-builder.diff737 bytesznerol
#2 INCOMPLETE-display_an_error-2548823-2.patch971 bytesznerol

Comments

znerol created an issue. See original summary.

znerol’s picture

znerol commented
StatusFileSize
new INCOMPLETE-display_an_error-2548823-2.patch971 bytes
znerol’s picture

znerol commented
Issue tags: -DX (Developer Experience)

Ok, seems that this is not so easy. If there is a mismatch between the dumped container and an updated class (e.g., changed type hints), then the exception (or is it an error?) is thrown during service instantiation. I.e., it would be necessary to override Container::get(), catch, wrap and rethrow any exceptions from there. But that method is obviously in the critical path.

Example bt:

Recoverable fatal error: Argument 1 passed to Drupal\Core\Controller\ControllerResolver::__construct() must be an instance of Symfony\Bridge\PsrHttpMessage\HttpMessageFactoryInterface, instance of Drupal\Core\DependencyInjection\ClassResolver given, called in /home/lo/Documents/prj/drupal-8-bootstrap/sites/default/files/php/service_container/service_container_prod_17922066/f3094d8ee18b9c6a5c465280ae8d5e65e1de4cadc6904e3d4fa0bda5dc9e5d1a.php on line 2489 and defined in Drupal\Core\Controller\ControllerResolver->__construct() (line 58 of core/lib/Drupal/Core/Controller/ControllerResolver.php).
Drupal\Core\Controller\ControllerResolver->__construct(Object)
Drupal\Core\DependencyInjection\Container\prod\service_container_prod_17922066->getControllerResolverService()
Symfony\Component\DependencyInjection\Container->get('controller_resolver')
Drupal\Core\DependencyInjection\Container\prod\service_container_prod_17922066->getHttpKernel_BasicService()
Symfony\Component\DependencyInjection\Container->get('http_kernel.basic')
Drupal\Core\DependencyInjection\Container\prod\service_container_prod_17922066->getHttpMiddleware_SessionService()
Symfony\Component\DependencyInjection\Container->get('http_middleware.session')
Drupal\Core\DependencyInjection\Container\prod\service_container_prod_17922066->getHttpMiddleware_KernelPreHandleService()
Symfony\Component\DependencyInjection\Container->get('http_middleware.kernel_pre_handle')
Drupal\Core\DependencyInjection\Container\prod\service_container_prod_17922066->getHttpMiddleware_PageCacheService()
Symfony\Component\DependencyInjection\Container->get('http_middleware.page_cache')
Drupal\Core\DependencyInjection\Container\prod\service_container_prod_17922066->getHttpMiddleware_ReverseProxyService()
Symfony\Component\DependencyInjection\Container->get('http_middleware.reverse_proxy')
Drupal\Core\DependencyInjection\Container\prod\service_container_prod_17922066->getHttpMiddleware_NegotiationService()
Symfony\Component\DependencyInjection\Container->get('http_middleware.negotiation')
Drupal\Core\DependencyInjection\Container\prod\service_container_prod_17922066->getHttpKernelService()
Symfony\Component\DependencyInjection\Container->get('http_kernel')
Drupal\Core\DrupalKernel->getHttpKernel()
Drupal\Core\DrupalKernel->handle(Object)
znerol’s picture

znerol commented

In case of PHP errors, it is obviously necessary to handle that in the error handler.

Maybe examine the backtrace and try to guess if the origin was a service instantiation - but that's a bit too fragile for my taste.

znerol’s picture

znerol commented
StatusFileSize
new break-entity-form-builder.diff737 bytes
new constructor-arguments-mismatch-before-2509898.png33.79 KB

I think that even before #2509898: Additional uncaught exception thrown while handling exception after service changes, the rebuild-message wasn't always displayed when the compiled container got out of date. I tried some things with commit 883c209 and it seems to me that the message only appeared when things were seriously screwed up in the bootstrap or the render pipeline. But if a higher level service has issues, then a Recoverable fatal error appears. For example, when breaking the entity form builder (see diff), then the result is the message shown in the attached screenshot.

The only way I found so far to provoke the rebuild-message with the aforementioned commit is to simply stop the database. In that case, the error handler freaks out because of the reasons discussed in the other issue.

That said I'm not sure whether we can actually present a meaningful message if things are screwed up in the compiled container - but I'm pretty sure that the rebuild-message we removed in #2521852: Make it possible to use your own exception handler never really worked as intended.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.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.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.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.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.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.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.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.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.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.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should 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.

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

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.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: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should 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: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

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

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

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.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.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.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.5.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

smustgrave’s picture

smustgrave commented
Status: Active » Postponed (maintainer needs more info)
Issue tags: +stale-issue-cleanup

Thank you for creating this issue to improve Drupal.

We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

znerol’s picture

znerol commented
Status: Postponed (maintainer needs more info) » Closed (works as designed)