[RFC] Supports 'finally' keyword for PHP exceptions

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 7:41 PM, Alexey Zakhlestin indeyets@gmail.com
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/

--

--
Atenciosamente,
Rafael Kassner

Will it work without "catch" in your implementation?
nope for now.

but if it is needed, I can implemente it

Yes, please.

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

--

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:
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.

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

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/

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?

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