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/
>>>>
>>>
>>>
>
没有评论:
发表评论