Le 16/06/2011 10:40, Oleg Stepura a écrit :
Hi!
Well, actually I do not want to throw an exception on /NOTICE /and
/WARNING /errors. *That is not the reason to stop the workflow*. But I
need to be notified about this errors to be able to find and fix it.
Your error handler calls the parent one, which throws an exception when
an error occurs (or a WARNING or NOTICE depending of its level of
reporting). So it stops the workflow. If you don't want an exception,
don't use an error handler that throws an exception.
I suppose it's not only me who will try to port his old working code
into Symfony2. And me and these people would want to know about all
errors that happen during execution. So error notification is a needed
feature.
I still do not understand why an error that was triggered inside the
controller action code has lost the request scope. Why? As far as I
could imagine, before any action is called the scope is entered, and
after it is left - the scope is left. So when an error was triggered
and handled the scope should be entered. This is the thing I'm missing.
And is there any thoughts on what will be the better way to get a
request object in the code I've written for the error handling? Here
the link again: https://gist.github.com/1027184
<https://gist.github.com/1027184>
One solution is to try to get a request object from DIC and if it
fails - instantiate it again with Request::createFromGlobals(). But
that is not a good solution since the request object was already
constructed somewhere.
Thanks!
--
Christophe | Stof
--
If you want to report a vulnerability issue on symfony, please send it to
security at symfony-project.com
You received this message because you are subscribed to the Google
Groups "symfony developers" group.
To post to this group, send email to symfony-devs@googlegroups.com
To unsubscribe from this group, send email to
symfony-devs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
