Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Consider creating a debugging component #6828

Closed
schmittjoh opened this Issue · 4 comments

4 participants

@schmittjoh

There are a few classes which I think would be beneficial to extract into their own component:

  • ErrorHandler
  • ExceptionHandler: There is already one for HTML, but Application::renderException should ideally be extracted to a dedicated class as well
  • FlattenException
@bamarni

:+1:

I'd also suggest that this component gets handled by the framework in its own event listener (eg. kernel.request with the highest priority) instead of Kernel::init() because currently a kernel can't be safely unserialized, it leads to weird things (cf. #6254).

This would also allow some cool features like displaying a raw message if it's an ajax request (instead of a symfony HTML template) for a quick debug with Firebug and co.

@stof
Collaborator

@bamarni initializing the exception handler in kernel.request would mean it would quite never be called. Currently, it is only called in 3 cases:

  • when an exception occurs during the booting of the kernel (which happens way before the kernel.request event is dispatched), which is a place where exception are likely to happen (as soon as you do a mistake in your configuration for instance)
  • when the ExceptionController fails to turn the exception catched by the kernel handling into a response because its code throws an exception again (which generally happens when you do a mistake in your Twig error template, which should not go in prod).
  • when an exception occurs during the kernel.response event (after the kernel exception handling)

The handling of ajax requests is what you should do in the exception controller, which is the place intended to display error pages in prod (IIRC, the ExceptionHandler is only enabled in debug mode anyway)

@bamarni

About the ajax rendering I was indeed talking about the ExceptionHandler in debug mode, not production error pages. If the kernel.request event is too late then I can just forget about this feature as the Request object wouldn't be accessible (or maybe relying directly on $_SERVER? it's not really the "symfony" way but it's for debug mode).

I've opened another discussion for my second point (#6834).

@fabpot fabpot referenced this issue from a commit
Commit has since been removed from the repository and is no longer available.
@fabpot fabpot referenced this issue from a commit
Commit has since been removed from the repository and is no longer available.
@fabpot fabpot closed this in 2ff0927
@fabpot fabpot referenced this issue from a commit
@fabpot fabpot merged branch fabpot/debug-component (PR #7441)
This PR was merged into the master branch.

Discussion
----------

[Debug] added the component (closes #6828, closes #6834, closes #7330)

| Q             | A
| ------------- | ---
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | no
| Deprecations? | yes
| Tests pass?   | yes
| Fixed tickets | #6828, #6834, #7330
| License       | MIT
| Doc PR        | symfony/symfony-docs#2479

You can use the individual tools, or register them all:

```php
use Symfony\Component\Debug\Debug;

Debug::enable();
```

Changes in Symfony SE: symfony/symfony-standard#523

Commits
-------

f693128 fixed typos
1ab1146 [Debug] fixed minor bugs
daa3a3c [Debug] changed composer to accept more versions
e455269 [Debug] ensured that the Debug tools can only be registered once
946bfb2 [Debug] made the exception handler independant of HttpFoundation
2b305c2 added a main Debug class to ease integration
2ff0927 [Debug] added the component (closes #6828, closes #6834, closes #7330)
6d552c9
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.