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/
>>>>
>>>
>>>
>
