Problem/Motivation

Our kernel exception handling was written as a quick'n'dirty "make it work for now" implementatoin. It's not extensible, it's barely comprehensible, it ties a bunch of different possible ways of handling exceptions into a single mega method, it's needlessly complex with potentially multiple levels of subrequest... really it has no redeeming value at all. (I can say that since I wrote it.)

Proposed resolution

Eliminate the ExceptionController concept entirely. Just wire all exception handling to the kernel exception event directly, breaking the various and sundry options down to different listeners. Each listener can decide for itself if it wants to handle or pass on the exception.

For the common case of handling HTTP exceptions, we provide a utility base class that simplifies HTTP handling.

This approach was discussed with the Alexes at Twin Cities DrupalCamp.

Remaining tasks

Commit it.

This should make #2063303: A Drupal 8 AjaxResponse that must return a 403, returns a 403 and prints "A fatal error occurred: " much easier to resolve, too.

User interface changes

None.

API changes

Contrib modules may now sanely add exception handling, especially for custom accept header formats. For details see the change notice draft.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Status: Needs review » Needs work

The last submitted patch, error-handling-revamp.patch, failed testing.

dawehner’s picture

  • +1 for splitting it up and give people the freedom to adapt things partially
  • These setResponse listeners should have a quite low priority so that other normal exception listener are always ran. Head is:
    public static function getSubscribedEvents()
        {
            return array(
                KernelEvents::EXCEPTION => array('onKernelException', -128),
            );
        }
  • Ensure that Fast404 has a higher priority as the other ones
Crell’s picture

Status: Needs work » Needs review
FileSize
49.84 KB

Fixed a lot of stupid errors, plus #2. It should actually install now. :-) Let's see what else fails.

Status: Needs review » Needs work

The last submitted patch, 3: error-handling-revamp.patch, failed testing.

Crell’s picture

Status: Needs work » Needs review
FileSize
52.28 KB

This should get all of phpunit passing.

There's still an issue with simpletest. Somehow, all drupalPostForm() calls from simpletest are now 404ing. How that's happening I have no idea. Suggestions welcome.

Status: Needs review » Needs work

The last submitted patch, 5: error-handling-revamp.patch, failed testing.

Crell’s picture

Status: Needs work » Needs review
FileSize
52.28 KB

Well that was silly...

Status: Needs review » Needs work

The last submitted patch, 7: 2323759-modularize-error-handling.patch, failed testing.

dawehner’s picture

Status: Needs work » Needs review
FileSize
53.13 KB
3.39 KB

Probably something like this.

Status: Needs review » Needs work

The last submitted patch, 9: 2323759-modularize-error-handling-9.patch, failed testing.

Crell’s picture

Status: Needs work » Needs review
FileSize
58.65 KB
25.38 KB

Let's see how this fares. Note to self: There are non-HTTP exceptions. :-) Also, we now log everything regardless of what type of exception it is.

Also with a nice big interdiff. And crap, I didn't see dawehner's patch before I wrote this. :-( Interdiff is against #7.

Status: Needs review » Needs work

The last submitted patch, 11: 2323759-modularize-error-handling.patch, failed testing.

Crell’s picture

Status: Needs work » Needs review
FileSize
59.28 KB
646 bytes

Well let's try it with dawehner's priority change... (The other changes were already made by #11, effectively.)

Status: Needs review » Needs work

The last submitted patch, 13: 2323759-modularize-error-handling.patch, failed testing.

Crell’s picture

Status: Needs work » Needs review
FileSize
59.49 KB
2.96 KB

This should get some of them. I think there's probably a few fails that are happening because we're throwing more accurate exceptions now and the tests can't handle that, but let's confirm.

Status: Needs review » Needs work

The last submitted patch, 15: 2323759-modularize-error-handling.patch, failed testing.

dawehner’s picture

Issue tags: +WSCCI

...

dawehner’s picture

Status: Needs work » Needs review
FileSize
59.88 KB
693 bytes

Started to fix a couple of the failures.

Status: Needs review » Needs work

The last submitted patch, 18: 2323759-exception-18.patch, failed testing.

Crell’s picture

I think that was the wrong interdiff. :-)

dawehner’s picture

FileSize
4.59 KB

here it is.

dawehner’s picture

Status: Needs work » Needs review
FileSize
60.7 KB
2.31 KB

Some further improvements.

Status: Needs review » Needs work

The last submitted patch, 22: exception-2323759-22.patch, failed testing.

Crell’s picture

+++ b/core/lib/Drupal/Core/EventSubscriber/HttpExceptionSubscriberBase.php
@@ -62,6 +62,10 @@ protected static function getPriority() {
+    // Make the exception available for example when rendering a block.
+    $event->getRequest()->attributes->set('exception', $exception);

Is this something we're doing already but I forgot to keep in the conversion, or is this adding something to attributes? (Because I know Mark and catch will object to the latter.)

Crell’s picture

Status: Needs work » Needs review
FileSize
62.88 KB
5.37 KB

Yeesh! Found at least some of them. In both cases it was caused by existing shortcomings of the codebase that we tripped over. I've left big @todo and explanations for both of them.

Status: Needs review » Needs work

The last submitted patch, 25: 2323759-modularize-error-handling.patch, failed testing.

dawehner’s picture

Is this something we're doing already but I forgot to keep in the conversion, or is this adding something to attributes? (Because I know Mark and catch will object to the latter.)

This is done something which we have done earlier, see (ExceptionListener)

    protected function duplicateRequest(\Exception $exception, Request $request)
    {
        $attributes = array(
            '_controller' => $this->controller,
            'exception' => FlattenException::create($exception),
  1. +++ b/core/lib/Drupal/Core/EventSubscriber/DefaultExceptionHtmlSubscriber.php
    @@ -0,0 +1,123 @@
    +  }
    +}
    

    .

  2. +++ b/core/lib/Drupal/Core/EventSubscriber/HttpExceptionSubscriberBase.php
    @@ -0,0 +1,106 @@
    +    if ($exception instanceof HttpException && (empty($handled_formats) || in_array($format, $handled_formats))) {
    +      $method = 'on' . $exception->getStatusCode();
    

    Note: There is a dedicated interface for the http exception.

dawehner’s picture

Status: Needs work » Needs review
FileSize
67.19 KB
5.93 KB

Status: Needs review » Needs work

The last submitted patch, 28: 2323759-exception-28.patch, failed testing.

Crell’s picture

+++ b/core/modules/node/src/NodeForm.php
@@ -67,6 +67,7 @@ protected function prepareEntity() {
     $node = $this->entity;
     // Set up default values, if required.
     $type = entity_load('node_type', $node->bundle());
+    db_query('SELECT a from {NODE}')->execute();
     $this->settings = $type->getModuleSettings('node');

Er, debug code maybe?

dawehner’s picture

Status: Needs work » Needs review
FileSize
66.68 KB
517 bytes

Damn you are right, let's try it again.

Crell’s picture

dawhener++

  1. +++ b/core/lib/Drupal/Core/EventSubscriber/ExceptionLoggingSubscriber.php
    @@ -0,0 +1,109 @@
    +  public static function getSubscribedEvents() {
    +    $events[KernelEvents::EXCEPTION][] = ['onException', -10];
    +    return $events;
    +  }
    

    The logger listener should have a very high priority so that it always fires. A negative priority means most custom/contrib listeners would implicitly bypass logging, which I doubt is desirable.

  2. +++ b/core/lib/Drupal/Core/EventSubscriber/Fast404ExceptionHtmlSubscriber.php
    @@ -0,0 +1,83 @@
    +  protected static function getPriority() {
    +    // A very high priority so that it can take precedent over anything else,
    +    // and thus be fast.
    +    return -5;
    +  }
    

    Shouldn't this also have a positive priority, so that it happens really early? That seems rather the point of the Fast404 listener.

Crell’s picture

Change record drafted: https://www.drupal.org/node/2331613 (Just to get out in front for a change...)

chx’s picture

Status: Needs review » Needs work

Regarding CustomPageExceptionHtmlSubscriber

  1. $this->systemSiteSettings = $config_factory->get('system.site'); in a constructor imo is a bit too much.
  2. $subrequest should imo be $sub_request but also I think it'd be cleaner + more visible if the Request::create arguments were broken out into variables and changed on POST. Why POST only? Do we not need to consider, I dunno, PUT and stuff?
  3. Can we unify on403 and on404 into a helper? Do they differ beyond page.403 vs page.404 and HTTP_FORBIDDEN vs HTTP_NOT_FOUND ?
  4. More importantly there is no try-catch. What happens if the subrequest handling throws an exception?
  5. Is -50 important? If so, what happens to a -500 or a 0 weight subscriber? DefaultExceptionHtmlSubscriber has a comment... But then Fast404ExceptionHtmlSubscriber has -5 claiming it to be very high. Also, in ParamConversionEnhancer we change from 0 to 75. Undocumented magic numbers worry me especially when I don't understand the consequences. The doxygen on HttpExceptionSubscriberBase::getPriority doesn't really help. What does it mean to have a "first attempt"...?

\ No newline at end of file tsk, tsk.

+ if (in_array($format, ['drupal_modal', 'drupal_dialog', 'drupal_ajax', 'hal_json'])) { there's no way hardwiring them like that is not going to backfire. Move it to a service argument or something.

$this->logger->get('page not found')->warning(String::checkPlain($request->attributes->get('_system_path'))); That's odd. Watchdog had messages and variables separately and we didn't escape on logging. Why do we do that now?

Crell’s picture

Discussing with chx and dawehner in IRC:

* We'll add notes about what the default/significant priorities are to the subscriber base class. For most cases, the 0 default should be fine.
* Point 2, that's existing code that's just being cut/pasted. It probably could be made more robust but I'd prefer to punt that to a later issue.
* Point 3 is specifically for the HTML handling. We'll have both methods share a utility method to reduce duplication there.
* Point 4: The subrequests in CustomPageExceptionHtmlSubscriber we can toss a try-catch around. If anything happens we turn everything into a bare 500 message, because we can't do much else.
* We can replace the if check above with something that examines the Accept header directly and just does a strpos for "json". Since this is the "catch of last resort" it's OK if that may have a few false positives in it. (We'll still check for core's 3 custom formats since they don't have json in their mime type.)
* And we still need to fix the priorities as noted in #32.

Crell’s picture

Status: Needs work » Needs review
FileSize
68.13 KB
11.81 KB

I think this addresses all the points from #32 and #34. Thanks, chx.

Status: Needs review » Needs work

The last submitted patch, 36: 2323759-modularize-error-handling.patch, failed testing.

dawehner’s picture

Crell, the king of introducing changes which he should know better due to earlier versions of the patch.

  1. +++ b/core/lib/Drupal/Core/EventSubscriber/CustomPageExceptionHtmlSubscriber.php
    @@ -100,28 +83,47 @@ public function on403(GetResponseForExceptionEvent $event) {
    +        // If an error happened in the subrequest we can't do much else.
    +        // Instead, do nothing.  The DefaultExceptionHandler will catch the
    +        // original exception and handle it normally.
    

    Didn't previous code logged the exception at least? (See ExceptionListener)

  2. +++ b/core/lib/Drupal/Core/EventSubscriber/DefaultExceptionSubscriber.php
    @@ -197,20 +210,25 @@ public function onException(GetResponseForExceptionEvent $event) {
    +    // Make an educated guess that any Accept header type that includes "json"
    +    // can probably handle a generic JSON response for errors. As above, for
    +    // any format this doesn't catch or that wants custom handling should
    +    // register its own exception listener.
    +    foreach ($request->getAcceptableContentTypes() as $mime) {
    

    What happens if browser vendors decided at some point that they actually also accept json by default? At least we have to add a @todo which checks that we should use HTML in case it has a higher priority has json.

  3. +++ b/core/lib/Drupal/Core/EventSubscriber/ExceptionLoggingSubscriber.php
    @@ -103,7 +103,7 @@ public function onException(GetResponseForExceptionEvent $event) {
    -    $events[KernelEvents::EXCEPTION][] = ['onException', -10];
    +    $events[KernelEvents::EXCEPTION][] = ['onException', 100];
    
    +++ b/core/lib/Drupal/Core/EventSubscriber/Fast404ExceptionHtmlSubscriber.php
    @@ -51,7 +51,7 @@ public function __construct(ConfigFactoryInterface $config_factory, HttpKernelIn
    -    return -5;
    +    return 200;
    

    Sorry again, these changes are wrong! Subscribers do convert an application specific exception by default on priority 0 into a HTTP specific one. ALSO exception logging should for example not log a ResourceNotFoundException but a 403/404 one, which results from that.

Crell’s picture

Issue summary: View changes
Status: Needs work » Needs review
FileSize
70.07 KB
7.05 KB

*bows* Thank you, thank you!

1) Implicitly I suppose, but not explicitly. I've added some explicit logging.

2) Tweaked a bit. If you allow html and json, you get html, because I can't imagine anyone consciously doing that other than a browser with its shotgun approach.

3) We can't have a negative priority or we will skip logging any exception for a contrib module that uses the default priority for a custom format. That's no good. Let's try moving the others.

Also, I realized we didn't have an issue summary yet. Oopsies. Fixed that.

dawehner’s picture

Okay.

tim.plunkett’s picture

The actual substance of the changes seems good, just some questions about the periphery and then some coding standards nitpicks.

  1. +++ b/core/core.services.yml
    @@ -196,6 +196,11 @@ services:
    +  logger.channel.php:
    

    Usually we've named these logger.channel.[subsystem|module], what's the significance of "php" here?

  2. +++ b/core/includes/menu.inc
    @@ -561,7 +561,7 @@ function menu_local_tasks($level = 0) {
    -    if (!empty($route_name)) {
    +    if (!\Drupal::request()->attributes->has('exception') && !empty($route_name)) {
    

    Are we going to have to sprinkle this in everywhere? Hope this is just one...

  3. +++ b/core/lib/Drupal/Core/EventSubscriber/CustomPageExceptionHtmlSubscriber.php
    @@ -0,0 +1,141 @@
    +<?php
    +/**
    + * @file
    + * Contains Drupal\Core\EventSubscriber\DefaultExceptionHtmlSubscriber
    
    +++ b/core/lib/Drupal/Core/EventSubscriber/DefaultExceptionHtmlSubscriber.php
    @@ -0,0 +1,123 @@
    +<?php
    +/**
    + * @file
    + * Contains Drupal\Core\EventSubscriber\DefaultExceptionHtmlSubscriber
    
    +++ b/core/lib/Drupal/Core/EventSubscriber/DefaultExceptionSubscriber.php
    @@ -0,0 +1,252 @@
    +<?php
    +/**
    + * @file
    + * Contains Drupal\Core\EventSubscriber\DefaultExceptionSubscriber
    
    +++ b/core/lib/Drupal/Core/EventSubscriber/ExceptionTestSiteSubscriber.php
    @@ -0,0 +1,65 @@
    +<?php
    +/**
    + * @file
    + * Contains Drupal\Core\EventSubscriber\ExceptionTestSiteSubscriber
    
    +++ b/core/lib/Drupal/Core/EventSubscriber/Fast404ExceptionHtmlSubscriber.php
    @@ -0,0 +1,83 @@
    +<?php
    +/**
    + * @file
    + * Contains Drupal\Core\EventSubscriber\Fast404ExceptionHtmlSubscriber
    
    +++ b/core/lib/Drupal/Core/EventSubscriber/HttpExceptionSubscriberBase.php
    @@ -0,0 +1,128 @@
    +<?php
    +/**
    + * @file
    + * Contains \Drupal\Core\EventSubscriber\HttpExceptionSubscriberBase.
    

    Missing line before docblock, missing leading \

  4. +++ b/core/lib/Drupal/Core/EventSubscriber/CustomPageExceptionHtmlSubscriber.php
    @@ -0,0 +1,141 @@
    +  /**
    +   * @var \Drupal\Core\Path\AliasManagerInterface
    +   */
    +  protected $aliasManager;
    +
    +  /**
    +   * @var \Symfony\Component\HttpKernel\HttpKernelInterface
    +   */
    +  protected $httpKernel;
    +
    +  /**
    +   * @var \Psr\Log\LoggerInterface
    +   */
    +  protected $logger;
    
    +++ b/core/lib/Drupal/Core/EventSubscriber/DefaultExceptionHtmlSubscriber.php
    @@ -0,0 +1,123 @@
    +  /**
    +   * @var \Drupal\Core\Page\HtmlFragmentRendererInterface
    +   */
    +  protected $fragmentRenderer;
    +
    +  /**
    +   * @var \Drupal\Core\Page\HtmlPageRendererInterface
    +   */
    +  protected $htmlPageRenderer;
    
    +++ b/core/lib/Drupal/Core/EventSubscriber/DefaultExceptionSubscriber.php
    @@ -0,0 +1,252 @@
    +  /**
    +   * @var \Drupal\Core\Page\HtmlFragmentRendererInterface
    +   */
    +  protected $fragmentRenderer;
    +
    +  /**
    +   * @var \Drupal\Core\Page\HtmlPageRendererInterface
    +   */
    +  protected $htmlPageRenderer;
    
    +++ b/core/lib/Drupal/Core/EventSubscriber/ExceptionLoggingSubscriber.php
    @@ -0,0 +1,109 @@
    +  /**
    +   * @var \Drupal\Core\Logger\LoggerChannelFactoryInterface
    +   */
    +  protected $logger;
    ...
    +   * Constructs a new ExceptionLoggingSubscriber.
    +   *
    +   * @param \Drupal\Core\Logger\LoggerChannelFactoryInterface $logger
    +   */
    +  public function __construct(LoggerChannelFactoryInterface $logger) {
    
    +++ b/core/lib/Drupal/Core/EventSubscriber/Fast404ExceptionHtmlSubscriber.php
    @@ -0,0 +1,83 @@
    +  /**
    +   * @var \Symfony\Component\HttpKernel\HttpKernelInterface
    +   */
    +  protected $httpKernel;
    

    These are missing their one liners.

  5. +++ b/core/lib/Drupal/Core/EventSubscriber/CustomPageExceptionHtmlSubscriber.php
    @@ -0,0 +1,141 @@
    +  }
    +}
    
    +++ b/core/lib/Drupal/Core/EventSubscriber/DefaultExceptionHtmlSubscriber.php
    @@ -0,0 +1,123 @@
    +  }
    +}
    \ No newline at end of file
    
    +++ b/core/lib/Drupal/Core/EventSubscriber/DefaultExceptionSubscriber.php
    @@ -0,0 +1,252 @@
    +  }
    +}
    
    +++ b/core/lib/Drupal/Core/EventSubscriber/ExceptionJsonSubscriber.php
    @@ -0,0 +1,67 @@
    +  }
    +}
    
    +++ b/core/lib/Drupal/Core/EventSubscriber/ExceptionLoggingSubscriber.php
    @@ -0,0 +1,109 @@
    +  }
    +}
    
    +++ b/core/lib/Drupal/Core/EventSubscriber/ExceptionTestSiteSubscriber.php
    @@ -0,0 +1,65 @@
    +  }
    +}
    
    +++ b/core/lib/Drupal/Core/EventSubscriber/Fast404ExceptionHtmlSubscriber.php
    @@ -0,0 +1,83 @@
    +  }
    +}
    

    Missing blank line at end of file (in some) and before end of class (in most)

  6. +++ b/core/lib/Drupal/Core/EventSubscriber/DefaultExceptionHtmlSubscriber.php
    @@ -0,0 +1,123 @@
    +  /**
    +   * @var string
    +   *
    +   * One of the error level constants defined in bootstrap.inc.
    +   */
    +  protected $errorLevel;
    
    +++ b/core/lib/Drupal/Core/EventSubscriber/DefaultExceptionSubscriber.php
    @@ -0,0 +1,252 @@
    +  /**
    +   * @var string
    +   *
    +   * One of the error level constants defined in bootstrap.inc.
    +   */
    +  protected $errorLevel;
    

    The one line description should be first, blank line, then @var

  7. +++ b/core/lib/Drupal/Core/EventSubscriber/ExceptionTestSiteSubscriber.php
    @@ -0,0 +1,65 @@
    +   * @todo The $headers array appears to not actually get used at all in the
    +   * original code. It's quite possible that this entire method is now
    +   * vestigial and can be removed.
    

    The extra lines in multiline @todos should be indented 2 spaces

  8. +++ b/core/modules/shortcut/shortcut.module
    @@ -320,15 +321,9 @@ function shortcut_preprocess_page(&$variables) {
    +  if (shortcut_set_edit_access() && !\Drupal::request()->attributes->has('exception')) {
    

    Here's another one. Just those two? Why? Can we get a code comment why those two places need to check for an exception?

dawehner’s picture

FileSize
13.54 KB
70.35 KB

Okay let's ensure that this issue doesn't start to sleep.

Usually we've named these logger.channel.[subsystem|module], what's the significance of "php" here?

Well, we used to have watchdog('php') calls, 'logger.channel.php' is an exact replacement for that.

Are we going to have to sprinkle this in everywhere? Hope this is just one...

Here's another one. Just those two? Why? Can we get a code comment why those two places need to check for an exception?

Well, they want to have special behavior on exception pages, it is as simple as that.

Let's fix those as well as some more issues.

Crell’s picture

Thanks, dawehner!

I can't RTBC this but I feel it is ready to be.

tim.plunkett’s picture

Status: Needs review » Reviewed & tested by the community

I agree that it's ready. Thanks for responding to my comment, @dawehner!

alexpott’s picture

Status: Reviewed & tested by the community » Needs work

This looks like a really sensible clean up. ExceptionController and ExceptionListener were not mentioned in an existing CRs and I don't think we need one here.

  1. +++ b/core/core.services.yml
    @@ -736,16 +741,44 @@ services:
    +  exception.custom_page_html:
    +    class: Drupal\Core\EventSubscriber\ExceptionJsonSubscriber
    +    tags:
    +      - { name: event_subscriber }
    +    arguments: ['@config.factory', '@path.alias_manager', '@http_kernel']
    +  exception.custom_page_html:
    +    class: Drupal\Core\EventSubscriber\CustomPageExceptionHtmlSubscriber
    +    tags:
    +      - { name: event_subscriber }
    +    arguments: ['@config.factory', '@path.alias_manager', '@http_kernel', '@logger.channel.php']
    

    Duplicate service keys? Missing json exception test coverage?

  2. +++ b/core/lib/Drupal/Core/EventSubscriber/DefaultExceptionSubscriber.php
    @@ -0,0 +1,276 @@
    +    // of message to be displayed, and unconditionnaly in update.php.
    

    unconditionally is misspelt

  3. +++ b/core/lib/Drupal/Core/EventSubscriber/DefaultExceptionSubscriber.php
    @@ -0,0 +1,276 @@
    +   * @todo This should probably check the error reporting leve.
    

    Needs an issue and to finish the final word.

  4. +++ b/core/lib/Drupal/Core/EventSubscriber/HttpExceptionSubscriberBase.php
    @@ -0,0 +1,129 @@
    + * Utilty base class for exception subscribers.
    

    Utility misspelt

  5. +++ b/core/lib/Drupal/Core/EventSubscriber/HttpExceptionSubscriberBase.php
    @@ -0,0 +1,129 @@
    + * module-provided listeners will naturaly take precedence over them.
    

    naturally misspelt

  6. +++ b/core/modules/shortcut/shortcut.module
    @@ -12,6 +12,7 @@
     use Drupal\Core\Url;
    ...
    +use Symfony\Component\HttpKernel\Exception\HttpExceptionInterface;
    

    Not used.

  7. +++ b/core/modules/simpletest/src/WebTestBase.php
    index 3a796ec..0000000
    --- a/core/tests/Drupal/Tests/Core/Controller/ExceptionControllerTest.php
    
    --- a/core/tests/Drupal/Tests/Core/Controller/ExceptionControllerTest.php
    +++ /dev/null
    
    +++ /dev/null
    index 5815ee1..0000000
    --- a/core/tests/Drupal/Tests/Core/EventSubscriber/ExceptionListenerTest.php
    
    --- a/core/tests/Drupal/Tests/Core/EventSubscriber/ExceptionListenerTest.php
    +++ /dev/null
    

    Do we have equivalent test coverage already existing?

dawehner’s picture

Status: Needs work » Needs review
FileSize
79.43 KB
16.16 KB

Duplicate service keys? Missing json exception test coverage?

Really good catch! Let's expand the test coverage.

unconditionally is misspelt

Storm tells you that, right?

Do we have equivalent test coverage already existing?

The first one is now covered by the new ExceptionHandlingTest, now also ExceptionListenerTest

Crell’s picture

Status: Needs review » Reviewed & tested by the community
+++ b/core/lib/Drupal/Core/EventSubscriber/DefaultExceptionHtmlSubscriber.php
@@ -71,6 +71,7 @@ protected function getHandledFormats() {
+    $response->headers->set('Content-type', 'text/html');

This is technically not necessary as text/html is the default on Response if nothing is specified. It doesn't hurt anything, though. The rest of the interdiff seems fine to me, though, so back to Alex.

alexpott’s picture

Status: Reviewed & tested by the community » Fixed

Committed 51a27d1 and pushed to 8.0.x. Thanks!

  • alexpott committed 51a27d1 on 8.0.x
    Issue #2323759 by Crell, dawehner: Modularize kernel exception handling.
    

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.