ExceptionController does not respect configured system.logging:error_level (verbose backtrace) [#2188523]

Originally fixed in #1158322-109: Add backtrace to all errors, but that patch somehow got lost in a collective push to backport the verbose backtrace facility to D7.

Attached patch re-implements the verbose error level (with backtrace) handling from errors.inc in ExceptionController::on500().

As an example, simply hack Entity\FieldableEntityStorageControllerBase::load() to throw an exception. In HEAD, you get the error message only. With this patch, you get a clean backtrace.

Note that Symfony Debug's FlattenException does not correctly process all arguments currently; see https://github.com/symfony/symfony/pull/10195

Screenshots:

before
After

Comment	File	Size	Author
#2	before.png	23.29 KB	dawehner
#2	after.png	100.88 KB	dawehner
	drupal8.exceptioncontroller-verbose.0.patch	4.14 KB	sun

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

sun

German

Karlsruhe

CreditAttribution: sun commented 4 February 2014 at 12:42

Please note:

Any discussion about using a different error/exception handler from Symfony/HttpKernel/Whatnot should go in a separate issue.

The one and only purpose of this issue here is to fix our current exception handling, so that errors can be properly debugged.

Thanks in advance :-)

Comment #2

dawehner

German

CreditAttribution: dawehner commented 8 February 2014 at 13:21

Issue summary:	View changes
Status:	Needs review	» Reviewed & tested by the community

File	Size
after.png	100.88 KB
before.png	23.29 KB

PS: Added some screenshots to show the greatness, which is part of the patch.

Any discussion about using a different error/exception handler from Symfony/HttpKernel/Whatnot should go in a separate issue.

Totally agree that we should not get crazy on this issue.

+ $error_level = $this->container->get('config.factory')->get('system.logging')->get('error_level');

I am a huge fun to avoid calling the container even if you have it available, but just use it to pass it along. As alternative you could inject still the actual dependency (config factory) additional,
but it does not seem to be really worth, given that this code will probably not be reused, neither really a production code, neither unit-testable.