Re: [PHP-DEV] Possibility to add finally to try/catch?

Hi!

> This is another feature that we know we can live without
> but those familiar with languages that have 'finally' like Java or Python
> know that
> it is very neat feature to have in some situations.

Last time we looked into it we couldn't make a clean implementation of
it that worked well. If anybody has good ideas about how to do it,
please provide a patch.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

I'll go ahead and create an RFC for this if nobody has any objections.
Then we could link to that instead of a bug ticket.

--Kris


On Tue, Feb 28, 2012 at 10:09 AM, Kiall Mac Innes <[email protected]>wrote:

> On Tue, Feb 28, 2012 at 5:36 PM, Stas Malyshev <[email protected]
> >wrote:
>
> > Last time we looked into it we couldn't make a clean implementation of it
> > that worked well. If anybody has good ideas about how to do it, please
> > provide a patch.
>
>
> Right - I don't claim, even for a moment, to have the slightly clue how
> easy/hard the implementation would be.
>
> But - I don't think that should stop the discussion, or even consensus
> gathering, of whether or not the feature should be implemented. If
> the consensus is that the feature is useful and will likely be accepted if
> formally proposed etc - that may encourage someone to spend the time on
> finding a clean and acceptable implementation!
>
> Anyway - Just my 2c.
>
> Kiall
>
> (P.S. Yes - I know there was an error in my ruby example.. Luckily I caused
> an exception while trying to raise an exception.. so no harm!)
>

A userland solution is possible making use of destructors to run anonymous
functions (see How can I get around the lack of a finally block in
PHP?http://stackoverflow.com/a/9244733/90527).
However, there are a number of issues with this approach (some are outlined
in the link), and language-level support would be preferable.

As for implementation, would it be possible to hook into whatever PHP has
in the way of frame disposal? That approach would have one of the same
issues as the userland solution ("finally" blocks won't run until the
current scope is exited), but is at least a partial solution. Would it be
possible to implement partial block scope? The idea being to add some sort
of guard when entering a block with an attached "finally", so that when the
block is exited, the finally runs. Please excuse my ignorance if none of
this is viable; I'll do my homework now.

Hi!

> As for implementation, would it be possible to hook into whatever PHP has
> in the way of frame disposal? That approach would have one of the same
> issues as the userland solution ("finally" blocks won't run until the
> current scope is exited), but is at least a partial solution. Would it be

No, "partial solution" is a no go. The solution should work like finally
is expected to work - finally block executed after the control leaves
try/catch/finally construct in any way. There are non-trivial things to
solve there - like how to correctly pass control if we have multiple
nested blocks or nested blocks inside finally, etc.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php