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