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?
Regards
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 :)
没有评论:
发表评论