(on Thursday, 07 January 2010, 10:19 PM +0200):
> Sorry to bring this up again but part of the problem still persists:
>
> The same pattern is used in Zend_Controller_Dispatcher_Standard, line
> 301. Can that be fixed as well? (r19833 fixed only
> Zend_Controller_Front)
> [ Show » ]
> Emil Ivanov added a comment - 05/Jan/10 03:05 AM The same pattern is
> used in Zend_Controller_Dispatcher_Standard, line 301. Can that be
> fixed as well? (r19833 fixed only Zend_Controller_Front)
>
> I posted the above as a comment ot the ZF-8558, but I don't have
> permission to reopen it?
I saw your comment, and have it flagged to update for the beta; been
putting out other, more urgent, fires this week.
Thanks for the due diligence in testing!
> 2009/12/22 Nicolas GREVET <ngrevet@alteo.fr>:
> > Yeah, sorry about this. We're currently iterating over the trunk in one of
> > our project and it kinda irritated us to see that nothing was working
> > anymore when we woke up this day. I guess we missed the point at that time;
> > but now, we totally understand the move behind this and fixed our code to
> > handle the change anyway.
> >
> > Maybe you should have warned though, because this was a major backward
> > incompatible move and a lot of us are working on the trunk on a daily basis.
> > But then again, I also fully understand that the trunk isn't really supposed
> > to be stable in the first place.
> >
> > Regards,
> > -- Nicolas
> >
> >
> > Matthew Weier O'Phinney a écrit :
> >>
> >> -- Nicolas GREVET <ngrevet@alteo.fr> wrote
> >> (on Friday, 18 December 2009, 04:52 PM +0100):
> >>>
> >>> I *really* hope this gets fixed soon.
> >>> I don't know how we're supposed to try/catch our own code if the
> >>> Zend Framework now only throws Zend_Controller_Exception for
> >>> everything that's thrown out of the code.
> >>
> >> Patience, everyone -- this is why the change is happening in a _minor_
> >> release cycle -- where we have a number of chances to correct issues
> >> prior to the stable release.
> >>
> >> This is corrected in trunk, and reflected in the 1.10.0alpha1 package
> >> released today.
> >>
> >>
> >>> Емил Иванов / Emil Ivanov a écrit :
> >>>>
> >>>> Thank you!
> >>>>
> >>>> Here is the issue: http://framework.zend.com/issues/browse/ZF-8558
> >>>>
> >>>> Cheers
> >>>>
> >>>> 2009/12/16 Matthew Weier O'Phinney <matthew@zend.com>:
> >>>>>
> >>>>> -- Емил Иванов / Emil Ivanov <emil.vladev@gmail.com> wrote
> >>>>> (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/
> >>>>>
> >>>>
> >>>>
> >>
> >
>
>
>
> --
> 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/
没有评论:
发表评论