This PR was merged into the master branch.
Commits
-------
d5948f1 Use KernelEvents constants in TraceableEventDispatcher
Discussion
----------
[HttpKernel] Use KernelEvents constants in TraceableEventDispatcher
Can't see any reason why we're not using constants here.
This PR was squashed before being merged into the master branch (closes#6232).
Commits
-------
7428bf9 [WebProfilerBundle] Some eye candy for deprecated calls
Discussion
----------
[WebProfilerBundle] Some eye candy for deprecated calls
.
@fabpot is [`|raw`](https://github.com/symfony/symfony/pull/new/deprecated#L0R117) a twig defect ?
---------------------------------------------------------------------------
by Baachi at 2012-12-08T09:12:12Z
Really nice 👍
---------------------------------------------------------------------------
by vicb at 2012-12-11T10:00:24Z
should be ready now
Since even fatal errors are catched and turned into exceptions by
ErrorHandler, all PHP errors can nicely be displayed by
ExceptionHandler. There is no need to set display_errors to true
anymore then.
Partially fixes#6254 on github.
This PR was squashed before being merged into the master branch (closes#6173).
Commits
-------
4878ec0 [HttpKernel] [WebProfilerBundle] Better handling of deprecated methods
Discussion
----------
[HttpKernel] [WebProfilerBundle] Better handling of deprecated methods
Bug fix: no
Feature addition: yes
Backwards compatibility break: yes, if you were expecting E_USER_DEPRECATED or E_DEPRECATED to throw an exception
Symfony2 tests pass: yes
Fixes the following tickets: #6139 partly, I'd go through and add the actual trigger_error() calls in another (or possibly one per component) PR
Todo: call trigger_error()
License of the code: MIT
Documentation PR: -
I added the deprecation count with the Exception icon in the Profiler Toolbar, and changed the color of it to be yellow for deprecations and red for exceptions (was yellow for exceptions).
---------------------------------------------------------------------------
by fabpot at 2012-12-03T09:43:09Z
Adding trigger_error calls should be done in one PR to ease the merging. thanks.
This PR was merged into the master branch.
Commits
-------
acfc750#2042 initial implementation of fatal error handler
Discussion
----------
Display traces for fatal errors
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: looks like yes
Fixes the following tickets: #2042 (partly)
License of the code: MIT
Output looks like on screen http://easycaptures.com/fs/uploaded/737/1191436899.png . I've added one line to css to prevent displaying standard xdebug trace http://easycaptures.com/fs/uploaded/737/5939488074.png
---------------------------------------------------------------------------
by Koc at 2012-11-08T21:55:41Z
So, community please advice me, how can I trigger `KernelEvents::EXCEPTION` event in `ErrorHandler` or `ExceptionHandler`? Or should I provide other event for this?
---------------------------------------------------------------------------
by stof at 2012-11-08T22:03:23Z
@Koc Don't. the exception handler is there to be the safe guard when developing, and does not depend on the kernel (which would be required to trigger the event). If you were triggering the listener again, it would mean that any exception thrown in a listener would lead to a loop.
And if it is for the fatal error handling, you simply cannot be sure the kernel is still available (and even less in a wokring state) at this point.
---------------------------------------------------------------------------
by Koc at 2012-11-08T22:06:31Z
But how can I notify logger (which will send me mail or just log this situation)?
---------------------------------------------------------------------------
by fabpot at 2012-11-09T07:33:41Z
The error handler is only registered when in debug mode in the Kernel and can be triggered very early in the handling of a request (even before we have access to the dispatcher or anything else). So, the current PR looks fine to me (apart from the typo and the lack of unit tests).
---------------------------------------------------------------------------
by Koc at 2012-11-09T09:13:03Z
> The error handler is only registered when in debug mode
Ooh! I haven't see that before. But the goal - be notified about errors by email or log-file. Like now exceptions with traces from site emails to me.
---------------------------------------------------------------------------
by fabpot at 2012-11-09T09:20:54Z
I think there are two goals. The first one being to have nice pages in the development environment when a fatal error occurs. And this PR addresses that feature quite nicely. The second can be addressed in another PR.
---------------------------------------------------------------------------
by henrikbjorn at 2012-11-14T11:50:22Z
I have some questions about the ErrorHandler. Is there a reason for it only to be registered in an debug environment (which prod is not). Would assume that if i enable the ErrorHandler in productions aswell Monolog would log thoose instead of them just vanishing?
---------------------------------------------------------------------------
by Koc at 2012-11-14T12:01:50Z
I am thinking about it too. But as Fabien says it will another PR
---------------------------------------------------------------------------
by GromNaN at 2012-11-18T10:38:09Z
You should add a memory reserve to be able to handle "Out of memory" errors.
An example is here :
513d628966/lib/Raven/ErrorHandler.php (L91)513d628966/lib/Raven/ErrorHandler.php (L62)
---------------------------------------------------------------------------
by fabpot at 2012-11-28T11:35:21Z
@Koc can you finish this PR (probably by integrating the memory reserve as explained by @GromNaN)?
---------------------------------------------------------------------------
by Koc at 2012-11-28T11:46:12Z
of course, on this weekend
---------------------------------------------------------------------------
by Koc at 2012-12-02T17:44:44Z
@fabpot done
The ContainerAwareTraceableEventDispatcher class was tied to both the
Symfony container and the HttpKernel profiler. It made it non reusable
in another context.
The new TraceableEventDispatcher only keeps the HttpKernel profiler
integration and is able to wrap any other event dispatcher. It makes it
reusable in frameworks using the Symfony HttpKernel component like
Silex.
The only drawback is that we don't have access to the listener
priorities in the collected data anymore (but the listeners are still
ordered correctly). The change is still worth it I think.
Commits
-------
3dd3d58 [EventListener] Fix an issue with sub-requests
71bf279 cleanup
acdb325 [StopWatch] Provide a cleaner API
acd1287 [Stopwatch] rename the section event to avoid collisions
eb540be [Profiler] Allow profiling the terminate event
4ccdc53 [HttpKernel] Cleanup of PdoProfilerStorage
814876f [HttpKernel] Tweak the code of the ProfilerListener
Discussion
----------
[Profiler] Allow profiling the terminate event
This PR is mainly about allowing to profile the terminate event (i.e. see it in the timeline panel)
There are some other tweaks.
---------------------------------------------------------------------------
by vicb at 2012-02-02T14:43:20Z
please don't merge for now. good question. bad answer.
---------------------------------------------------------------------------
by vicb at 2012-02-06T15:05:46Z
While first commits were focused on problem solving, the last brings a clean API with the ability to re-open an existing section in order to add events (re-setting event origins and merging them were just hacks).
Should be ready to be merged.
_Edit: Sorry, couldn't resist adding a private helper class again!_
---------------------------------------------------------------------------
by stof at 2012-02-06T18:30:09Z
@vicb you should stop adding such classes defined in the same file. Otherwise we will have to change the CS (and to stop telling we respect the PSR-0 standard)
---------------------------------------------------------------------------
by vicb at 2012-02-06T18:33:36Z
Once again PSR-0 is about autoloading which is exactly why I do not want in such cases. CS are an other matter and yes I think they should be changed to allow this (and I am going to submit a PR right now).
The only argument I could accept is whether this class should be private or not.
---------------------------------------------------------------------------
by vicb at 2012-02-06T19:57:06Z
Thanks for your valuable feedback @stof
---------------------------------------------------------------------------
by fabpot at 2012-02-11T20:53:03Z
Have you tested it on a project? Because it breaks my simple examples (where I have some sub-requests).
---------------------------------------------------------------------------
by vicb at 2012-02-12T09:47:23Z
my bad, should be ok now.
