[RFC] Supports 'finally' keyword for PHP exceptions

Alexey Zakhlestin

14 years ago

On 24.07.2012, at 15:20, Laruence wrote:

> Hi:
>    As the previous threads disscussed,  I make a implemention.
>
>    here is the RFC: https://wiki.php.net/rfc/finally
>
>    any suggestions?

Will it work without "catch" in your implementation?

try {
doSomethingDangerous();
} finally {
doCleanup();
}

Laruence

14 years ago

On Tue, Jul 24, 2012 at 7:41 PM, Alexey Zakhlestin <indeyets@gmail.com> wrote:

>
> On 24.07.2012, at 15:20, Laruence wrote:
>
>> Hi:
>>    As the previous threads disscussed,  I make a implemention.
>>
>>    here is the RFC: https://wiki.php.net/rfc/finally
>>
>>    any suggestions?
>
> Will it work without "catch" in your implementation?

nope for now.

but if it is needed, I can implemente it

thanks

>
> try {
>     doSomethingDangerous();
> } finally {
>     doCleanup();
> }

--
Laruence  Xinchen Hui
http://www.laruence.com/

Rick Widmer

14 years ago

On 7/24/2012 5:45 AM, Laruence wrote:

> On Tue, Jul 24, 2012 at 7:41 PM, Alexey Zakhlestin <indeyets@gmail.com> wrote:
>>
>> On 24.07.2012, at 15:20, Laruence wrote:
>> Will it work without "catch" in your implementation?
> nope for now.
>
> but if it is needed, I can implemente it

Yes, please.

Rafael Kassner

14 years ago

Thanks Laruence.

If I perform something like this:

function test() {
try {
return 2;
} catch (Exception $e) {
} finally {
return 3;
}
}

What will be returned? There is no possibility to return something in
finally, or finally will overwrite the return?

On Tue, Jul 24, 2012 at 8:45 AM, Laruence <laruence@php.net> wrote:

> On Tue, Jul 24, 2012 at 7:41 PM, Alexey Zakhlestin <indeyets@gmail.com>
> wrote:
> >
> > On 24.07.2012, at 15:20, Laruence wrote:
> >
> >> Hi:
> >>    As the previous threads disscussed,  I make a implemention.
> >>
> >>    here is the RFC: https://wiki.php.net/rfc/finally
> >>
> >>    any suggestions?
> >
> > Will it work without "catch" in your implementation?
> nope for now.
>
> but if it is needed, I can implemente it
>
> thanks
> >
> > try {
> >     doSomethingDangerous();
> > } finally {
> >     doCleanup();
> > }
>
>
>
> --
> Laruence  Xinchen Hui
> http://www.laruence.com/
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--
Atenciosamente,
Rafael Kassner

Sebastian Krebs

14 years ago

Hi,

What should a return value in 'finally' mean?

Regards,
Sebastian

2012/7/24 Rafael Kassner <kassner@gmail.com>

Xinchen Hui

14 years ago

Sent from my iPhone

在 2012-7-24，19:51，Rafael Kassner <kassner@gmail.com> 写道：

Thanks Laruence.

If I perform something like this:

function test() {
try {
return 2;
} catch (Exception $e) {
} finally {
return 3;
}
}

What will be returned? There is no possibility to return something in
finally, or finally will overwrite the return?

overweite，although I think it make no sense return in finally block

But seems java allow that, so I implement it

Thanks

On Tue, Jul 24, 2012 at 8:45 AM, Laruence <laruence@php.net> wrote:

> On Tue, Jul 24, 2012 at 7:41 PM, Alexey Zakhlestin <indeyets@gmail.com>
> wrote:
> >
> > On 24.07.2012, at 15:20, Laruence wrote:
> >
> >> Hi:
> >>    As the previous threads disscussed,  I make a implemention.
> >>
> >>    here is the RFC: https://wiki.php.net/rfc/finally
> >>
> >>    any suggestions?
> >
> > Will it work without "catch" in your implementation?
> nope for now.
>
> but if it is needed, I can implemente it
>
> thanks
> >
> > try {
> >     doSomethingDangerous();
> > } finally {
> >     doCleanup();
> > }
>
>
>
> --
> Laruence  Xinchen Hui
> http://www.laruence.com/
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--
Atenciosamente,
Rafael Kassner

Laruence

14 years ago

Hi:
try{}finally{} implemented,
https://github.com/laruence/php-src/commit/90cad0a0001ef48396146c69382a25ebe0a60474

the test scripts in that commit are examples

thanks


On Tue, Jul 24, 2012 at 7:41 PM, Alexey Zakhlestin <indeyets@gmail.com> wrote:

>
> On 24.07.2012, at 15:20, Laruence wrote:
>
>> Hi:
>>    As the previous threads disscussed,  I make a implemention.
>>
>>    here is the RFC: https://wiki.php.net/rfc/finally
>>
>>    any suggestions?
>
> Will it work without "catch" in your implementation?
>
> try {
>     doSomethingDangerous();
> } finally {
>     doCleanup();
> }

--
Laruence  Xinchen Hui
http://www.laruence.com/

Paul Dragoonis

14 years ago

On Tue, Jul 24, 2012 at 12:20 PM, Laruence <laruence@php.net> wrote:

> Hi:
>     As the previous threads disscussed,  I make a implemention.
>
>     here is the RFC: https://wiki.php.net/rfc/finally
>
>     any suggestions?
>
> thanks
>
> --
> Laruence  Xinchen Hui
> http://www.laruence.com/
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Now this is the kind of stuff that's important to the upcoming
versions of PHP instead of talking about brace-less expressions.

We definitely need this, try {} catch {} finally {}.

Push this for discussion, in two weeks call a vote, I definitely see
this going through.

- Paul.

Nikita Popov

14 years ago

On Tue, Jul 24, 2012 at 1:20 PM, Laruence <laruence@php.net> wrote:

> Hi:
>     As the previous threads disscussed,  I make a implemention.
>
>     here is the RFC: https://wiki.php.net/rfc/finally
>
>     any suggestions?

The finally clause comes with a very strong promise that the code in
the clause will run in absolutely any case (short of sigkill, maybe).
In particular this means that...
... if a die() is execute somewhere in the try clause (or a called
function) the finally clause must still be run.
... if a parse error or other fatal error occurs in the try clause (or
called function) the finally clause must still be run.
... if the user interrupts the process the finally clause must still be run.

Basically this requires that all of the actions that are currently
fatal need to be converted to exceptions. E.g. Python has special
SystemExit and KeyboardInterrupt exceptions, as well as SyntaxError
and so on.

I obviously think that PHP should adopt this model too (as it gives
the programmer more control), but until all fatal actions are turned
into exceptions, I'm strongly against introducing "finally". The main
point of the clause is to have a guarantee, and that is simply
currently not present. You actually get a better guarantee if you just
use destructors.

Nikita

Levi Morrison

14 years ago

On Tue, Jul 24, 2012 at 7:35 AM, Nikita Popov <nikita.ppv@gmail.com> wrote:

> On Tue, Jul 24, 2012 at 1:20 PM, Laruence <laruence@php.net> wrote:
>> Hi:
>>     As the previous threads disscussed,  I make a implemention.
>>
>>     here is the RFC: https://wiki.php.net/rfc/finally
>>
>>     any suggestions?
>
> The finally clause comes with a very strong promise that the code in
> the clause will run in absolutely any case (short of sigkill, maybe).
> In particular this means that...
> ... if a die() is execute somewhere in the try clause (or a called
> function) the finally clause must still be run.
> ... if a parse error or other fatal error occurs in the try clause (or
> called function) the finally clause must still be run.
> ... if the user interrupts the process the finally clause must still be run.
>
> Basically this requires that all of the actions that are currently
> fatal need to be converted to exceptions. E.g. Python has special
> SystemExit and KeyboardInterrupt exceptions, as well as SyntaxError
> and so on.
>
> I obviously think that PHP should adopt this model too (as it gives
> the programmer more control), but until all fatal actions are turned
> into exceptions, I'm strongly against introducing "finally". The main
> point of the clause is to have a guarantee, and that is simply
> currently not present. You actually get a better guarantee if you just
> use destructors.
>
> Nikita
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

I definitely agree with Mr. Nikita Popov. Unless we have a
guarantee of `finally` running for PHP fatal errors, then this is not
particularly useful.

Andrew Faulds

14 years ago

On 24/07/12 14:40, Levi Morrison wrote:

> On Tue, Jul 24, 2012 at 7:35 AM, Nikita Popov <nikita.ppv@gmail.com> wrote:
>> On Tue, Jul 24, 2012 at 1:20 PM, Laruence <laruence@php.net> wrote:
>>> Hi:
>>>      As the previous threads disscussed,  I make a implemention.
>>>
>>>      here is the RFC: https://wiki.php.net/rfc/finally
>>>
>>>      any suggestions?
>> The finally clause comes with a very strong promise that the code in
>> the clause will run in absolutely any case (short of sigkill, maybe).
>> In particular this means that...
>> ... if a die() is execute somewhere in the try clause (or a called
>> function) the finally clause must still be run.
>> ... if a parse error or other fatal error occurs in the try clause (or
>> called function) the finally clause must still be run.
>> ... if the user interrupts the process the finally clause must still be run.
>>
>> Basically this requires that all of the actions that are currently
>> fatal need to be converted to exceptions. E.g. Python has special
>> SystemExit and KeyboardInterrupt exceptions, as well as SyntaxError
>> and so on.
>>
>> I obviously think that PHP should adopt this model too (as it gives
>> the programmer more control), but until all fatal actions are turned
>> into exceptions, I'm strongly against introducing "finally". The main
>> point of the clause is to have a guarantee, and that is simply
>> currently not present. You actually get a better guarantee if you just
>> use destructors.
>>
>> Nikita
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
> I definitely agree with Mr. Nikita Popov. Unless we have a
> guarantee of `finally` running for PHP fatal errors, then this is not
> particularly useful.
>

I also agree with Mr. Popov here. PHP's fatal errors are, well, fatal,
meaning we can do absolutely nothing about them. I guess that's
something to change for PHP6: making them into serious exceptions, but
ones that can be caught (maybe a different class, like Java's
RuntimeErrors and Exceptions, IIRC). Obviously things like running out
of memory can't be dealt with, though.

Laruence

14 years ago

On Tue, Jul 24, 2012 at 9:43 PM, Andrew Faulds <ajf@ajf.me> wrote:

> On 24/07/12 14:40, Levi Morrison wrote:
>>
>> On Tue, Jul 24, 2012 at 7:35 AM, Nikita Popov <nikita.ppv@gmail.com>
>> wrote:
>>>
>>> On Tue, Jul 24, 2012 at 1:20 PM, Laruence <laruence@php.net> wrote:
>>>>
>>>> Hi:
>>>>      As the previous threads disscussed,  I make a implemention.
>>>>
>>>>      here is the RFC: https://wiki.php.net/rfc/finally
>>>>
>>>>      any suggestions?
>>>
>>> The finally clause comes with a very strong promise that the code in
>>> the clause will run in absolutely any case (short of sigkill, maybe).
>>> In particular this means that...
>>> ... if a die() is execute somewhere in the try clause (or a called
>>> function) the finally clause must still be run.
>>> ... if a parse error or other fatal error occurs in the try clause (or
>>> called function) the finally clause must still be run.
>>> ... if the user interrupts the process the finally clause must still be
>>> run.
>>>
>>> Basically this requires that all of the actions that are currently
>>> fatal need to be converted to exceptions. E.g. Python has special
>>> SystemExit and KeyboardInterrupt exceptions, as well as SyntaxError
>>> and so on.
>>>
>>> I obviously think that PHP should adopt this model too (as it gives
>>> the programmer more control), but until all fatal actions are turned
>>> into exceptions, I'm strongly against introducing "finally". The main
>>> point of the clause is to have a guarantee, and that is simply
>>> currently not present. You actually get a better guarantee if you just
>>> use destructors.
>>>
>>> Nikita
>>>
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>> I definitely agree with Mr. Nikita Popov. Unless we have a
>> guarantee of `finally` running for PHP fatal errors, then this is not
>> particularly useful.
>>
> I also agree with Mr. Popov here. PHP's fatal errors are, well, fatal,
> meaning we can do absolutely nothing about them. I guess that's something to
> change for PHP6: making them into serious exceptions, but ones that can be
> caught (maybe a different class, like Java's RuntimeErrors and Exceptions,
> IIRC). Obviously things like running out of memory can't be dealt with,
> though.

Hi:
FATAL ERRORS in PHP is kind of static errors, which means it can be
avoided by well programing.

however as Rasmus said,  it's not we can't guarantee
that(zend_try), it's just not necessary for the 'finally' keyword,

*finally for exceptions*

thanks

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

--
Laruence  Xinchen Hui
http://www.laruence.com/

Laruence

14 years ago

On Tue, Jul 24, 2012 at 9:35 PM, Nikita Popov <nikita.ppv@gmail.com> wrote:

> On Tue, Jul 24, 2012 at 1:20 PM, Laruence <laruence@php.net> wrote:
>> Hi:
>>     As the previous threads disscussed,  I make a implemention.
>>
>>     here is the RFC: https://wiki.php.net/rfc/finally
>>
>>     any suggestions?
>
> The finally clause comes with a very strong promise that the code in
> the clause will run in absolutely any case (short of sigkill, maybe).
> In particular this means that...
> ... if a die() is execute somewhere in the try clause (or a called
> function) the finally clause must still be run.
> ... if a parse error or other fatal error occurs in the try clause (or
> called function) the finally clause must still be run.
> ... if the user interrupts the process the finally clause must still be run.

I am really can not agree with you on this point.

there is runtime error and static error in PHP.

it is enough for finally guarantee that the block will be run while
*Exception* threw.

if in your opinion, then I think finally is also nouse for java, since
user could also call exit(some like that ).

thank

>
> Basically this requires that all of the actions that are currently
> fatal need to be converted to exceptions. E.g. Python has special
> SystemExit and KeyboardInterrupt exceptions, as well as SyntaxError
> and so on.
>
> I obviously think that PHP should adopt this model too (as it gives
> the programmer more control), but until all fatal actions are turned
> into exceptions, I'm strongly against introducing "finally". The main
> point of the clause is to have a guarantee, and that is simply
> currently not present. You actually get a better guarantee if you just
> use destructors.
>
> Nikita

--
Laruence  Xinchen Hui
http://www.laruence.com/

Rasmus Lerdorf

14 years ago

On 07/24/2012 06:35 AM, Nikita Popov wrote:

> On Tue, Jul 24, 2012 at 1:20 PM, Laruence <laruence@php.net> wrote:
>> Hi:
>>     As the previous threads disscussed,  I make a implemention.
>>
>>     here is the RFC: https://wiki.php.net/rfc/finally
>>
>>     any suggestions?
>
> The finally clause comes with a very strong promise that the code in
> the clause will run in absolutely any case (short of sigkill, maybe).

No it doesn't, at least not in Java. A fatal Java error or an explicit
call to System.exit() will cause the finally clause to not be executed.
It is a simple exception-level construct and doesn't in any way promise
to be called in a fatal error situation. And regardless of what Java
does, we are free to define it and provide whatever promises we want
here, but keeping it in line with Java's implementation makes sense to me.

-Rasmus

Andrew Faulds

14 years ago

On 24/07/12 16:16, Rasmus Lerdorf wrote:

> On 07/24/2012 06:35 AM, Nikita Popov wrote:
>> On Tue, Jul 24, 2012 at 1:20 PM, Laruence <laruence@php.net> wrote:
>>> Hi:
>>>      As the previous threads disscussed,  I make a implemention.
>>>
>>>      here is the RFC: https://wiki.php.net/rfc/finally
>>>
>>>      any suggestions?
>> The finally clause comes with a very strong promise that the code in
>> the clause will run in absolutely any case (short of sigkill, maybe).
> No it doesn't, at least not in Java. A fatal Java error or an explicit
> call to System.exit() will cause the finally clause to not be executed.
> It is a simple exception-level construct and doesn't in any way promise
> to be called in a fatal error situation. And regardless of what Java
> does, we are free to define it and provide whatever promises we want
> here, but keeping it in line with Java's implementation makes sense to me.
>
> -Rasmus
>

Yeah, finally{} won't happen in absolutely any case. But if there's an
exception that's uncaught it *should* still run.

Nikita Popov

14 years ago

On Tue, Jul 24, 2012 at 5:16 PM, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:

>> The finally clause comes with a very strong promise that the code in
>> the clause will run in absolutely any case (short of sigkill, maybe).
>
> No it doesn't, at least not in Java. A fatal Java error or an explicit
> call to System.exit() will cause the finally clause to not be executed.
> It is a simple exception-level construct and doesn't in any way promise
> to be called in a fatal error situation. And regardless of what Java
> does, we are free to define it and provide whatever promises we want
> here, but keeping it in line with Java's implementation makes sense to me.

I was writing this out of a Python perspective, which gives strong
guarantees for finally. Java indeed reserves the right to not run
finally if System.exit is called.

Still my point stands. If fatal errors and die are not handled by
finally the feature does not make sense to me. You simply can't do any
kind of remotely important cleanup in there (like releasing locks
etc).

Please don't forget that in PHP a lot of stuff throws a fatal error.
Some simple oversight like calling $foo->bar()->baz() while
$foo->bar() can also return false or null can lead to a fatal error
that's easily missed during testing.

Similarly die; is commonly called in code doing header redirects. I
think it would be unacceptable to not run cleanup clauses in that
case.

Another, separate point against finally is that in PHP (unlike many
other languages) most (all?) built-in resources clean up after
themselves. So if you open a file you don't have to worry about
closing it again. It'll do that all by itself as soon as it goes out
of scope. The same applies to database handles, etc. As PHP uses
refcount based garbage collection the resource is actually cleaned up
right away, not just at the next GC run (which could be problematic if
you open up many files in a row).

Nikita

Rasmus Lerdorf

14 years ago

On 07/24/2012 10:01 AM, Nikita Popov wrote:

> Another, separate point against finally is that in PHP (unlike many
> other languages) most (all?) built-in resources clean up after
> themselves. So if you open a file you don't have to worry about
> closing it again. It'll do that all by itself as soon as it goes out
> of scope. The same applies to database handles, etc. As PHP uses
> refcount based garbage collection the resource is actually cleaned up
> right away, not just at the next GC run (which could be problematic if
> you open up many files in a row).

Which is the argument for why finally doesn't need to worry about the
fatal-error case. Most resources are cleaned up on a fatal already,
including your lock example, so it isn't an issue. finally is
exception-level for intra-app cleanup, not for request shutdown cleanup.
We already have shutdown functions for that case.

-Rasmus

Paul Dragoonis

14 years ago

On Tue, Jul 24, 2012 at 6:20 PM, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:

> On 07/24/2012 10:01 AM, Nikita Popov wrote:
>
>> Another, separate point against finally is that in PHP (unlike many
>> other languages) most (all?) built-in resources clean up after
>> themselves. So if you open a file you don't have to worry about
>> closing it again. It'll do that all by itself as soon as it goes out
>> of scope. The same applies to database handles, etc. As PHP uses
>> refcount based garbage collection the resource is actually cleaned up
>> right away, not just at the next GC run (which could be problematic if
>> you open up many files in a row).
>
> Which is the argument for why finally doesn't need to worry about the
> fatal-error case. Most resources are cleaned up on a fatal already,
> including your lock example, so it isn't an issue. finally is
> exception-level for intra-app cleanup, not for request shutdown cleanup.
> We already have shutdown functions for that case.

Exactly what I've been thinking.

If people are already doing die() in their code, they already don't
care about manually freeing up resources and will let php do its
shutdown process as normal.

I think existing concerns about php's resource freeing upon fatal
errors have been accidentally merged with the finally{} proposal,
which shouldn't be looking to change how things work, but provide an
additional block for further control.

I have had to workaround stuff in my PHP apps because of a lack of
finally{} block, and I hope it makes its way into the next iteration.

Thanks,
Paul.

Nikita Popov

14 years ago

On Tue, Jul 24, 2012 at 7:25 PM, Paul Dragoonis <dragoonis@gmail.com> wrote:

> I have had to workaround stuff in my PHP apps because of a lack of
> finally{} block, and I hope it makes its way into the next iteration.

I think it would add a lot to this discussion if you could show us
what real-life use case you have there that desperately needs
try/finally support. That would probably be a lot more helpful in
understanding the issue than just looking at dummy try/finally blocks
:)

Nikita

Stas Malyshev

14 years ago

Hi!

> Still my point stands. If fatal errors and die are not handled by
> finally the feature does not make sense to me. You simply can't do any
> kind of remotely important cleanup in there (like releasing locks
> etc).

Well, I'm sorry you don't understand it but I think you are too focused
on exactly copying what you are accustomed to, and this is not the goal
for PHP.
I don't know what you mean by "important cleanup" but if you mean you do
some persistent things that absolutely need to be cleaned up by code, I
have very bad news for you. PHP is not the language that can do it. PHP
script can be terminated at any moment - by the webserver, by the OS, by
other means - and that'd be just that, it would cease to exist and no
code will be run. finally can not and will not solve this problem. It is
not meant to solve this problem. It is meant to solve specific use-case
of using temporary resources in a block of code and cleaning them
immediately (as opposed to waiting until request-level cleanup).

Fortunately, in my many years of working with PHP I don't think I ever
saw any case where simple OS functions coupled with more powerful
constructs like transactions were not enough to cleanup anything that
PHP script could do.

> Similarly die; is commonly called in code doing header redirects. I
> think it would be unacceptable to not run cleanup clauses in that
> case.

If you need cleanups on the request level, you already have shutdown
functions. Those, btw, aren't guaranteed to run in every case too -
there can be situations, albeit rare, that shutdown could fail and thus
some cleanup not run (e.g. the process being killed, PHP getting out of
memory, etc.). Also, there could be more frequent situation that your
shutdown code has a bug which causes it to terminate early. Which btw
may be a case with Python code too - unless you wrap every statement in
a separate finally clause you have the same issue.

> Another, separate point against finally is that in PHP (unlike many
> other languages) most (all?) built-in resources clean up after
> themselves. So if you open a file you don't have to worry about
> closing it again. It'll do that all by itself as soon as it goes out

You don't have to, but in some cases you better to if you write more
than two-liner, since otherwise, while the file does not survive the
request, with suitable scope it may linger much longer than you expect.
So in some cases having shorter-scope cleanups can be helpful. Of
course, you can also do pretty much the same with RAII pattern - so it's
not strictly necessary. But may be nice to have.

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

Stas Malyshev

14 years ago

Hi!

> In particular this means that...
> ... if a die() is execute somewhere in the try clause (or a called
> function) the finally clause must still be run.
> ... if a parse error or other fatal error occurs in the try clause (or
> called function) the finally clause must still be run.
> ... if the user interrupts the process the finally clause must still be run.

No I don't think so. finally clause is used to clean up resources
allocated/initialized by the code inside try clause. All the above
functions will terminate the script and thus all the resources that were
allocated will be freed. If you so something more persistent, then a)
use shutdown functions b) know that the script can be killed at any
moment anyway, so PHP can not guarantee you anything. I don't see how
finally ever implied it would be called on die().

> Basically this requires that all of the actions that are currently
> fatal need to be converted to exceptions. E.g. Python has special
> SystemExit and KeyboardInterrupt exceptions, as well as SyntaxError
> and so on.

So basically this requires that PHP will be converted to Python. ;) I'd
almost write an RFC but then I remembered somebody already wrote Python! :)

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

Andrew Faulds

14 years ago

On 24/07/12 18:31, Stas Malyshev wrote:

> Hi!
>
>> In particular this means that...
>> ... if a die() is execute somewhere in the try clause (or a called
>> function) the finally clause must still be run.
>> ... if a parse error or other fatal error occurs in the try clause (or
>> called function) the finally clause must still be run.
>> ... if the user interrupts the process the finally clause must still be run.
> No I don't think so. finally clause is used to clean up resources
> allocated/initialized by the code inside try clause. All the above
> functions will terminate the script and thus all the resources that were
> allocated will be freed. If you so something more persistent, then a)
> use shutdown functions b) know that the script can be killed at any
> moment anyway, so PHP can not guarantee you anything. I don't see how
> finally ever implied it would be called on die().
>
>> Basically this requires that all of the actions that are currently
>> fatal need to be converted to exceptions. E.g. Python has special
>> SystemExit and KeyboardInterrupt exceptions, as well as SyntaxError
>> and so on.
> So basically this requires that PHP will be converted to Python. ;) I'd
> almost write an RFC but then I remembered somebody already wrote Python! :)
>
>

PHP risks losing some of its uniqueness to fixing things, unfortunately.
But losing bad features and moving forward is good, right?

--
Andrew Faulds
http://ajf.me/

Stas Malyshev

14 years ago

Hi!

> PHP risks losing some of its uniqueness to fixing things, unfortunately.
> But losing bad features and moving forward is good, right?

I'm not sure what you are talking about here, but I'm sure I can not
accept argument "Python does it this way, so we must do it exactly the
same way even if we have to rewrite whole engine and change whole
approach of how things done in PHP". If you want exactly what Python
does, you always have Python. It's fine to look into what Python does,
but how it fits PHP and uses cases of the *PHP* users should always come
first, and implementation details of how Python or any other language
does things can be a guidance, but never should override this. So if
Python does finally in certain way, fine, but it's no no way by itself
defines how PHP should do it.

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

Andrew Faulds

14 years ago

On 24/07/12 18:38, Stas Malyshev wrote:

> Hi!
>
>
>> PHP risks losing some of its uniqueness to fixing things, unfortunately.
>> But losing bad features and moving forward is good, right?
> I'm not sure what you are talking about here, but I'm sure I can not
> accept argument "Python does it this way, so we must do it exactly the
> same way even if we have to rewrite whole engine and change whole
> approach of how things done in PHP". If you want exactly what Python
> does, you always have Python. It's fine to look into what Python does,
> but how it fits PHP and uses cases of the *PHP* users should always come
> first, and implementation details of how Python or any other language
> does things can be a guidance, but never should override this. So if
> Python does finally in certain way, fine, but it's no no way by itself
> defines how PHP should do it.

What?

I'm not suggesting PHP do things because Python does them. I'm just
saying that 1) keeping things because they've always been done one way
is not a good reason to keep them, and 2) just because Python does the
same or a similar thing, does not mean PHP is "turning into Python".

--
Andrew Faulds
http://ajf.me/

Johannes Schlueter

14 years ago

On Tue, 2012-07-24 at 19:20 +0800, Laruence wrote:

> Hi:
>     As the previous threads disscussed,  I make a implemention.
>
>     here is the RFC: https://wiki.php.net/rfc/finally
>
>     any suggestions?
>
> thanks

As PHP has destructors there is less need for "finally" compared to
other languages. What are the cases where an extra language construct is
needed? (i.e. one can also use C++-like RAII things ...)

The RFC is also missing to demonstrate the order of finally calls in
nested try-catch-blocks.

johannes

Andrew Faulds

14 years ago

On 24/07/12 14:48, Johannes Schlüter wrote:

> On Tue, 2012-07-24 at 19:20 +0800, Laruence wrote:
>> Hi:
>>      As the previous threads disscussed,  I make a implemention.
>>
>>      here is the RFC: https://wiki.php.net/rfc/finally
>>
>>      any suggestions?
>>
>> thanks
> As PHP has destructors there is less need for "finally" compared to
> other languages. What are the cases where an extra language construct is
> needed? (i.e. one can also use C++-like RAII things ...)
>
> The RFC is also missing to demonstrate the order of finally calls in
> nested try-catch-blocks.
>
> johannes
>
>
>

Tempfiles come to mind. Also, yes, PHP has destructors, but you are not
always dealing with custom-made objects to handle this. And you may want
something to happen before GC.

Johannes Schlueter

14 years ago

On Tue, 2012-07-24 at 14:50 +0100, Andrew Faulds wrote:

> > As PHP has destructors there is less need for "finally" compared to
> > other languages. What are the cases where an extra language construct is
> > needed? (i.e. one can also use C++-like RAII things ...)
> >
> > The RFC is also missing to demonstrate the order of finally calls in
> > nested try-catch-blocks.
> >
> >
> Tempfiles come to mind. Also, yes, PHP has destructors, but you are not
> always dealing with custom-made objects to handle this. And you may want
> something to happen before GC.

finally is no sufficient way to ensure tempfiles will be delete. Best
approach for that is to delete them after opening (but keep the
handle(s) open) so the OS will guarantee they are deleted. finally might
not be called (in the proposed implementation it isn't called after an
die()/exit() or a fatal error)

When not dealing with custom objects you might wrap them in a
RAII-Container. PHPs GC is mostly refcount-based and well defined. If
you keep a single reference to a RAII-container or something it is well
defined when it will be called. finally rules (especially with nested
try blocks) is an extra thing to be learned.

johannes


P.S. simple, untested, ad hoc example of a quite generic raii container:

class RAIIContainer {
private $cb;
public function __construct(callable $cb) {
$this->cb = $cb;
}
public function __destruct() {
$cb = $this->cb; $cb();
}
}

try {
$file = fopen(....);
$rc = new RAIIContainer(
function() use ($file) { if ($file) { unlink($file); }});

/* do something /
} catch (SomeException $e) {
}

here unlink will even be called at an exit() or something, certainly can
be made nice ... and yes an extra syntax might be "nicer" but is it
common enough to excuse making the language larger?

Anthony Ferrara

14 years ago

Johannes,

On Tue, Jul 24, 2012 at 9:48 AM, Johannes Schlüter
<johannes@schlueters.de>wrote:

> On Tue, 2012-07-24 at 19:20 +0800, Laruence wrote:
> > Hi:
> >     As the previous threads disscussed,  I make a implemention.
> >
> >     here is the RFC: https://wiki.php.net/rfc/finally
> >
> >     any suggestions?
> >
> > thanks
>
> As PHP has destructors there is less need for "finally" compared to
> other languages. What are the cases where an extra language construct is
> needed? (i.e. one can also use C++-like RAII things ...)
>

I'm not sure I agree with that statement. Finally is a routine level
cleanup tool, while destructors are object level cleanup tools. So while it
is possible to make every routine into an object, at some point it just
becomes ridiculous. That means that every method that allocates resources
would need to be a first-class object, which could get quite messy very
fast.

If you went by "possible", half the proposals for the language wouldn't be
accepted (password hashing, generators, goto, Class name to scalar
resolution, T_AS for closures, type hints, call-time dereferencing, traits,
classes, etc). All of that behavior is possible without the language sugar
that they bring. The main drive for adding them is that it makes a
developers life a lot easier. Rather than dealing with yet another level of
abstraction to add an object, adding a simple finally clause would make
implementing that sort of cleanup FAR easier.

Additionally, the destructor isn't called until the object goes out of
scope. That could be after the method call (a scope block higher). So the
only way to fully emulate the finally block would be to construct the
object inside of the method in question. So it's not as simple as "just put
it in a destructor and you'll be fine"...

My $0.02 at least...

Johannes Schlueter

14 years ago

On Tue, 2012-07-24 at 10:37 -0400, Anthony Ferrara wrote:

>
> If you went by "possible", half the proposals for the language
> wouldn't be accepted (password hashing, generators, goto, Class name
> to scalar resolution, T_AS for closures, type hints, call-time
> dereferencing, traits, classes, etc). All of that behavior is possible
> without the language sugar that they bring. The main drive for adding
> them is that it makes a developers life a lot easier. Rather than
> dealing with yet another level of abstraction to add an object, adding
> a simple finally clause would make implementing that sort of cleanup
> FAR easier.

That's why I asked for cases where this language construct is needed. I,
from my personal, limited, experience don't have that many needs for
this feature.

I however see that it makes try/catch blocks and stack frames more
expensive (both in CPU time and memory) and the language more complex.

Te best argument I saw in this discussion for adding it was "it's
possible and I want it". This I don't see as enough reason.

johannes

Stas Malyshev

14 years ago

On 7/24/12 4:20 AM, Laruence wrote:

> Hi:
>     As the previous threads disscussed,  I make a implemention.
>
>     here is the RFC: https://wiki.php.net/rfc/finally

I'm not seeing tests for the following situations:
1. Return from catch block.
2. Another try/catch block inside finally block.
3. Multiple nested functions with finally blocks.
4. Exception thrown in catch block.

Could you add those?

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

Xinchen Hui

14 years ago

发自我的 iPad

在 2012-7-25，1:50，Stas Malyshev <smalyshev@sugarcrm.com> 写道：

> On 7/24/12 4:20 AM, Laruence wrote:
>> Hi:
>>    As the previous threads disscussed,  I make a implemention.
>>
>>    here is the RFC: https://wiki.php.net/rfc/finally
>
> I'm not seeing tests for the following situations:
> 1. Return from catch block.
> 2. Another try/catch block inside finally block.
> 3. Multiple nested functions with finally blocks.
> 4. Exception thrown in catch block.

They are in the test scripts in commits,  But sure, I should note them out

Thanks

Laruence

14 years ago

Hi all:
Here are a test script lists, which I think could be help to
understand the current implemented behaviors:
try..catch..finally
https://github.com/laruence/php-src/blob/finally/Zend/tests/catch_finally_001.phpt
https://github.com/laruence/php-src/blob/finally/Zend/tests/catch_finally_002.phpt
https://github.com/laruence/php-src/blob/finally/Zend/tests/catch_finally_003.phpt
https://github.com/laruence/php-src/blob/finally/Zend/tests/catch_finally_004.phpt
https://github.com/laruence/php-src/blob/finally/Zend/tests/catch_finally_005.phpt
https://github.com/laruence/php-src/blob/finally/Zend/tests/catch_finally_006.phpt

try...finally
https://github.com/laruence/php-src/blob/finally/Zend/tests/try_finally_001.phpt
https://github.com/laruence/php-src/blob/finally/Zend/tests/try_finally_002.phpt
https://github.com/laruence/php-src/blob/finally/Zend/tests/try_finally_003.phpt

thanks
On Tue, Jul 24, 2012 at 7:20 PM, Laruence <laruence@php.net> wrote:

> Hi:
>     As the previous threads disscussed,  I make a implemention.
>
>     here is the RFC: https://wiki.php.net/rfc/finally
>
>     any suggestions?
>
> thanks
>
> --
> Laruence  Xinchen Hui
> http://www.laruence.com/

--
Laruence  Xinchen Hui
http://www.laruence.com/