Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.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
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | constructor-arguments-mismatch-before-2509898.png | 33.79 KB | znerol |
| #5 | break-entity-form-builder.diff | 737 bytes | znerol |
| #2 | INCOMPLETE-display_an_error-2548823-2.patch | 971 bytes | znerol |
Comments
Comment #2
znerol CreditAttribution: znerol commentedComment #3
znerol CreditAttribution: znerol commentedOk, 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:
Comment #4
znerol CreditAttribution: znerol commentedIn 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.
Comment #5
znerol CreditAttribution: znerol commentedI 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.