Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Consider creating a debugging component #6828

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
schmittjoh opened this issue Jan 22, 2013 · 5 comments
Closed

Consider creating a debugging component #6828

schmittjoh opened this issue Jan 22, 2013 · 5 comments

Comments

@schmittjoh
Copy link
Contributor

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
Copy link
Contributor

bamarni commented Jan 22, 2013

👍

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.

@wouterj
Copy link
Member

wouterj commented Jan 22, 2013

👍

@stof
Copy link
Member

stof commented Jan 22, 2013

@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
Copy link
Contributor

bamarni commented Jan 22, 2013

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 closed this as completed in 2ff0927 Apr 7, 2013
fabpot added a commit that referenced this issue Apr 7, 2013
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)
@TomasVotruba
Copy link
Contributor

Just found this out.

Application::renderException should ideally be extracted to a dedicated class as well

Took me few hours to figure out the Application can render exceptions. I looked at SymfonyStyle and other classes with OutputInterface. It would save me so much pain having this method out of the Application god class

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants