(on Wednesday, 16 December 2009, 05:58 PM +0200):
> Thank you for the response, Mathew.
>
> Let me try to explain it with some code:
>
> Application dispatching:
>
> $front = Zend_Controller_Front::getInstance();
> try {
> $front->dispatch();
> } catch (My_Controller_Outcome_Result $e) {
> $front->getResponse()->sendResponse();
> // Ignore
> }
>
> My_Controller_Outcome_Result exceptions usually indicate a redirect
> (or other event that should stop the execution)
>
> Prior to 19661 I was actually getting a My_Controller_Outcome_Result
> exception, but after that the instance is Zend_Controller_Exception,
> so the catch fails.
Ah, okay, that makes sense... can you open an issue requesting that this
particular change be reverted? It was one I was actually initially
unsure of anyways.
Thanks!
> I managed to locate the change in ZF:
>
> Zend_Controller_Dispatcher_Standard, line 300.
>
> Old code just does
>
> throw $e;
>
> while now:
>
> throw new Zend_Controller_Exception($e->getMessage(), $e->getCode(), $e);
>
> One possible solution that comes to mind is to catch the
> Zend_Exception and traverse all the previous exceptions until I get to
> one of mine, but it seems kind of hacky.
>
> Regards,
> Emil
>
> 2009/12/16 Matthew Weier O'Phinney <matthew@zend.com>:
> > -- Емил Иванов / Emil Ivanov <emil.vladev@gmail.com> wrote
> > (on Wednesday, 16 December 2009, 03:13 PM +0200):
> >> Problem:
> >> In 19661 (trunk) Mathew has committed a workaround for php's odd
> >> behavior of swallowing stack traces when re-throwing an exception. But
> >> the fix is by throwing the special Zend_Exception - effectively
> >> swallowing the old exception for consumption.
> >>
> >> Use case:
> >> I implemented a custom redirecting machinery that relies on exceptions
> >> to work - the reason is that when a redirect happens in stock ZF the
> >> execution is not terminated (I should call return in the action - but
> >> what about redirects not in the action method, but some other helper
> >> function?).
> >> What I did is throw a special exception, then wrap the call to
> >> Zend_Controller_Front::dispatch() in try/catch and wait for this
> >> exception. If caught - redirect and terminate. (Yes, I had to
> >> monkey-patch Zend_Test_PHPUnit_ControllerTestCase::dispatch() so set
> >> the FC::throwExceptions(true)).
> >>
> >> With the new change this is no longer possible.
> >
> > The change is actually part of this proposal:
> >
> > http://framework.zend.com/wiki/display/ZFPROP/previous+Exception+on+Zend_Exception+-+Marc+Bennewitz
> >
> > Its basic premise is to provide forward-compatibility with PHP 5.3
> > exceptions, which allow passing a "previous" exception as the third
> > argument to the constructor:
> >
> > try {
> > } catch (Exception $e) {
> > throw new Foo_Exception('Something failed', 0, $e);
> > }
> >
> > This provides the ability to see the original exception (and nest
> > exceptions) during debugging.
> >
> > When I merged the support to trunk, the only changes I made were to look
> > for places where exceptions were re-thrown, and to pass the third
> > argument. In a few cases, the original exception is rethrown (which is
> > really kind of a ridiculous practice), and I threw a new component
> > exception so that the full stack trace could be seen.
> >
> > >From your description, I'm really not sure what particular part of the
> > changeset is affecting you. Could you provide the customizations that
> > you have? That may help me better identify what has changed -- and how
> > you may need to adapt your code to accomodate the new exception
> > signature (which, again, is what the signature is in 5.3 and above).
> >
> > --
> > Matthew Weier O'Phinney
> > Project Lead | matthew@zend.com
> > Zend Framework | http://framework.zend.com/
> >
> >
>
>
>
> --
> My place to share my ideas:
> http://bolddream.com (now live :)
>
--
Matthew Weier O'Phinney
Project Lead | matthew@zend.com
Zend Framework | http://framework.zend.com/
没有评论:
发表评论