Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
On Wed, Jul 25, 2012 at 3:23 AM, Galen Wright-Watson ww.ga...@gmail.com wrote:
On Tue, Jul 24, 2012 at 5:03 AM, Xinchen Hui larue...@gmail.com wrote:
Sent from my iPhone
在 2012-7-24，19:51，Rafael Kassner kass...@gmail.com 写道：
Thanks Laruence.
If I perform something like this:
function test() {
try {
return 2;
} catch (Exception $e) {
} finally {
return 3;
}
}
Reminds me of nerd sniping at Google
(http://neil.fraser.name/news/2009/10/27/, bottom of the page).
Worse example:
$r = 1;
try {
return $r;
} catch (Exception $e) {
} finally {
$r = 2;
}
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
C# has perhaps more desirable behavior
(http://blogs.msdn.com/b/jmstall/archive/2006/10/05/finally_5f00_vs_5f00_return.aspx):
a return in a finally block is illegal, and the return value of a return
statement in a try block is copied from the variable before the finally
block is executed, so 1 will be returned. However, C# seems the odd one out
(http://www.gettingclever.com/2008/07/return-from-finally.html).
Hi:
overwrite or not is easy to change, I impelent this according to
java's behavior.
but if we all think not overwrite is better, it's easy to change
thanks
--
惠新宸laruence
Senior PHP Engineer
http://www.laruence.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
On Tue, Jul 24, 2012 at 9:43 PM, Andrew Faulds a...@ajf.me wrote: On 24/07/12 14:40, Levi Morrison wrote: On Tue, Jul 24, 2012 at 7:35 AM, Nikita Popov nikita@gmail.com wrote: On Tue, Jul 24, 2012 at 1:20 PM, Laruence larue...@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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
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
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
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();
}
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
On Tue, Jul 24, 2012 at 12:20 PM, Laruence larue...@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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
On Tue, Jul 24, 2012 at 7:41 PM, Alexey Zakhlestin indey...@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
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
On 7/24/2012 5:45 AM, Laruence wrote: On Tue, Jul 24, 2012 at 7:41 PM, Alexey Zakhlestin indey...@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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [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 8:45 AM, Laruence larue...@php.net wrote:
On Tue, Jul 24, 2012 at 7:41 PM, Alexey Zakhlestin indey...@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
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
Hi,
What should a return value in 'finally' mean?
Regards,
Sebastian
2012/7/24 Rafael Kassner kass...@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?
On Tue, Jul 24, 2012 at 8:45 AM, Laruence larue...@php.net wrote:
On Tue, Jul 24, 2012 at 7:41 PM, Alexey Zakhlestin indey...@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
[PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
Sorry ... to the list instead.
-- Forwarded message --
From: Sebastian Krebs krebs@gmail.com
Date: 2012/7/24
Subject: Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
To: Laruence larue...@php.net
Hi,
2012/7/24 Laruence larue...@php.net
On Tue, Jul 24, 2012 at 7:41 PM, Alexey Zakhlestin indey...@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
It is. 'catch()' usually means I can handle it (at least partially), but
when 'finally' it just means, that the current scop wants to clean up ;)
Additional I see myself already, that I misuse it like
$f = fopen($file, 'r+b');
try {
return search_in_file($f);
} finally {
fclose($f);
}
What I mean: I see myself already using 'finally' without ever expecting an
exception, just because it feels so easy to never forget anymore to cleanup
resources. Is this intentionally?
Regards,
Sebastian
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
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
Sent from my iPhone
在 2012-7-24，19:51，Rafael Kassner kass...@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 larue...@php.net wrote:
On Tue, Jul 24, 2012 at 7:41 PM, Alexey Zakhlestin indey...@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
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
On Tue, Jul 24, 2012 at 1:20 PM, Laruence larue...@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
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
On Tue, Jul 24, 2012 at 7:35 AM, Nikita Popov nikita@gmail.com wrote: On Tue, Jul 24, 2012 at 1:20 PM, Laruence larue...@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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
On 24/07/12 14:40, Levi Morrison wrote: On Tue, Jul 24, 2012 at 7:35 AM, Nikita Popov nikita@gmail.com wrote: On Tue, Jul 24, 2012 at 1:20 PM, Laruence larue...@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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
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?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
Johannes, On Tue, Jul 24, 2012 at 9:48 AM, Johannes Schlüter johan...@schlueters.dewrote: 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...
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
On Tue, Jul 24, 2012 at 9:35 PM, Nikita Popov nikita@gmail.com wrote: On Tue, Jul 24, 2012 at 1:20 PM, Laruence larue...@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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
On 07/24/2012 06:35 AM, Nikita Popov wrote: On Tue, Jul 24, 2012 at 1:20 PM, Laruence larue...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
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 larue...@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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
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 indey...@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/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
On Tue, Jul 24, 2012 at 5:16 PM, Rasmus Lerdorf ras...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
On Tue, Jul 24, 2012 at 6:20 PM, Rasmus Lerdorf ras...@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.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
On Tue, Jul 24, 2012 at 7:25 PM, Paul Dragoonis dragoo...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
发自我的 iPad 在 2012-7-25，1:50，Stas Malyshev smalys...@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 Could you add those? -- 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
