Completely overhaul the error catching and logging system.

Created on 2 March 2015, about 10 years ago
Updated 2 May 2025, 10 days ago

The Assertion Handling project is the beginning of a larger revision to how errors are handled which is the subject of this ticket - essentially it is just the Assertion Handler of this system so that it might squeak into the 8.0.x branch and get assertion additions underway as soon as possible.

This project has the larger goal of smoothing out how errors are handled in Drupal with a complete object oriented replacement. /core/includes/errors.inc will be replaced by the classes of this project which will live in core/lib/Drupal/Core/Errors.

The Well Formed Errors Initiative β†’ outlines much of what I wish to accomplish here, but a brief recap.

  1. Error Strings will be formalized to error string codes that map to yaml files with complete explanations of the errors and when possible links to relevant documentation.
  2. No more white screens of doom
  3. Begin the use of assert to maintain and document required program state so developers are warned when their new module's configuration file is invalid.
  4. Reintroduce trigger_error to throw E_USER_DEPRECATED notices where appropriate.

Specific to this project are these additions:

  1. Allow the developer to configure Drupal to use their favorite error handling system, though Whoops will be the default.
  2. Error configuration will be in htaccess via SetEnv so that it can be setup immediately after the autoloader is included and before the Drupal Kernal is loaded and main runtime boot comes into play. This will allow for all possible errors in drupal to be handled outside the autoloader, index.php and ErrorSystem class files.
  3. Allow the developer to log errors to the filesystem instead of or in addition to the database (useful since database connectivity can be lost)
  4. Simplify error handling as much as possible, and set this system to lazy load as much as possible for minimum overhead.
  5. Allow errors to be sent to the js console instead of being displayed inline.
  6. Provide a method to trace and dump, either through Whoops or symfony/vardumper

In short, make Drupal's crashes become the gentlest in the PHP ecosystem instead of the cryptic What the?? monstrosities they sometimes are now.

If this project is accepted and work begins on it then it will affect all developers profoundly - so commentary and input are requested. Later this week I'm going to draw up the class map proposal for this and begin the design of the API.

About the only module that will care alot about this system is devel, but I need to take a look at it and see if any parts of it could be or should be ported to core as part of this project.

✨ Feature request
Status

Postponed: needs info

Version

11.0 πŸ”₯

Component

base system

Created by

πŸ‡ΊπŸ‡ΈUnited States Aki Tendo

Live updates comments and jobs are added and updated live.
  • API change

    Changes an existing API or subsystem. Not backportable to earlier major versions, unless absolutely required to fix a critical bug.

  • stale-issue-cleanup

    To track issues in the developing policy for closing stale issues, [Policy, no patch] closing older issues

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡ΊπŸ‡ΈUnited States smustgrave

    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!

Production build 0.71.5 2024