PHP doesn't need 'finally'(bugs.php.net)
bugs.php.net
PHP doesn't need 'finally'
http://bugs.php.net/bug.php?id=32100
12 comments
In this case, do_something_finally() will never be called.
try {
throw new IOException("bad");
} catch ( NotAnIOException e) {
System.out.println("This is something I expected to happen.");
}
do_something_finally();
try {
throw new IOException("bad");
} catch ( NotAnIOException e) {
System.out.println("This is something I expected to happen.");
} catch (Exception e) {
do_something_finally();
throw e;
}
do_something_finally();Thanks, now that has a lot more sense
No, you're right. The code in the above example behaves differently than the finally version in the case where UNLOCK TABLE throws something.
This seems to be an example where the hack is preferred over the correct solution. The hack in this case is going to work almost all of the time.
I fail to see how throwing up an example of a hack is a good way to argue for or against a language feature. Generally speaking if the language is decent enough there is always a way to hack in some new semantics yourself (I'm looking at you, anonymous inner Java classes for closures), but language features allow you to compose and represent those semantics more elegantly. So, the argument shouldn't be "can we do this already with a hack" it should be "is this hack common enough that we should fix it."
The point the author is making is almost self-evidentally against his own conclusion: here's a common pattern that is broken, so we should not include this as a language feature???
This seems to be an example where the hack is preferred over the correct solution. The hack in this case is going to work almost all of the time.
I fail to see how throwing up an example of a hack is a good way to argue for or against a language feature. Generally speaking if the language is decent enough there is always a way to hack in some new semantics yourself (I'm looking at you, anonymous inner Java classes for closures), but language features allow you to compose and represent those semantics more elegantly. So, the argument shouldn't be "can we do this already with a hack" it should be "is this hack common enough that we should fix it."
The point the author is making is almost self-evidentally against his own conclusion: here's a common pattern that is broken, so we should not include this as a language feature???
Without the finally block, do_something_finally() will not be called if:
1. the try block returns
2. the catch block doesn't handle /all/ types of exceptions
The point of finally is that it's always, always, always executed.
1. the try block returns
2. the catch block doesn't handle /all/ types of exceptions
The point of finally is that it's always, always, always executed.
> The point of finally is that it's always, always, always executed.
Except when it's not. If you design a large system with the assumption that finally blocks always execute, you could end up with some data integrity issues when you get a power outage, an exception in your finally clause, a hung machine, or any other number of errors that a finally clause does nothing to address.
The finally clause is very useful, but to say that it will always (x3!) execute is somewhat perilous.
Except when it's not. If you design a large system with the assumption that finally blocks always execute, you could end up with some data integrity issues when you get a power outage, an exception in your finally clause, a hung machine, or any other number of errors that a finally clause does nothing to address.
The finally clause is very useful, but to say that it will always (x3!) execute is somewhat perilous.
According to the linked article, the second one will not run do_something_finall() since it is after the return statement. The second one however will...
Note, this does seem to be the case for javascript:
With finally http://jsfiddle.net/J5Cjt/
Without finally http://jsfiddle.net/C2vg7/
Note, this does seem to be the case for javascript:
With finally http://jsfiddle.net/J5Cjt/
Without finally http://jsfiddle.net/C2vg7/
Your first example will do_something_finally() before returning y and exiting the try-scope and method (unless an error has occurred). Your second example will return y without invoking do_something finally() (unless an error has occurred).
If an error occurs before "return y", both will behave equally.
Basically the finally-clause is guaranteed to be run always. This means that you can put your resource-cleanup logic there and know it will be invoked if errors occur or not, without the need to duplicate that logic within the catch-block.
Especially when the catch-block is set to rethrow (or just outright omitted) this saves the programmer a lot of time, code-duplication and makes the code more readable.
The reasons given for omitting it by the PHP team is factually incorrect and shows that they clearly don't understand how the feature is supposed to work. With that hindsight, it would be interesting to see how it would have been implemented if they had gone forward adding it instead of saying "no". It could have become a highly fascinating monster.
If an error occurs before "return y", both will behave equally.
Basically the finally-clause is guaranteed to be run always. This means that you can put your resource-cleanup logic there and know it will be invoked if errors occur or not, without the need to duplicate that logic within the catch-block.
Especially when the catch-block is set to rethrow (or just outright omitted) this saves the programmer a lot of time, code-duplication and makes the code more readable.
The reasons given for omitting it by the PHP team is factually incorrect and shows that they clearly don't understand how the feature is supposed to work. With that hindsight, it would be interesting to see how it would have been implemented if they had gone forward adding it instead of saying "no". It could have become a highly fascinating monster.
I don't think 'finally' is mandatory, I have never missed it, sure it may be syntactic sugar 1% of the time, but are we developing for the rare cases now?
This looks like a PHP version of the Ruby "ensure". http://web.njit.edu/all_topics/Prog_Lang_Docs/html/ruby/synt...
Can't you just implement finally in "userspace"? In Perl, you can implement it with object destruction -- you make an instance of an object whose destructor does the cleanup you want, and when it goes out of scope (exception thrown, return, etc.), the cleanup code is run.
It's extremely common to write code like:
(+) Also, don't cut-n-paste this code into your apps. It misses special cases. use Try::Tiny, TryCatch, etc. from the CPAN.
It's extremely common to write code like:
sub work_in_tmpdir(&) {
my $cwd = cwd;
my $guard = guard { chdir $cwd };
chdir mktmp;
$_[0]->();
}
print cwd; # /home/jon
work_in_tmpdir { print cwd; die "OH NOES" }; # /tmp/3sdjkh387dh
print cwd; # /home/jon
sub try(&;@) {
my ($code, %args) = @_;
my $guard;
$guard = guard { $args{finally}->() }
if exists $args{finally};
my $result = eval { $code->() };
if($args{catch} && !$result){
$args{catch}->($@);
}
return $result;
}
catch(&;@) {
return catch => @_;
}
finally(&) {
return finally => $_[0];
}
try { something_exceptional }
catch { warn "Something bad happened: $_[0] }
finally { cleanup };
(+) Also, don't cut-n-paste this code into your apps. It misses special cases. use Try::Tiny, TryCatch, etc. from the CPAN.
That's a neat example, but you're abusing Perl's syntax for that syntactic-sugar, and it doesn't work like that in PHP (e.g. parens cannot be omitted, and does this code even compile with "use strict"?)
It compiles with "use strict", and it's not abuse.
The reason you can't compile it is because guard is not defined, nor are cwd, cleanup, and the other placeholder functions I used. When you are relying on the parser to add parens for you (and let you omit "sub"), you have to have the function in scope. Compare:
The reason you can't compile it is because guard is not defined, nor are cwd, cleanup, and the other placeholder functions I used. When you are relying on the parser to add parens for you (and let you omit "sub"), you have to have the function in scope. Compare:
use strict;
sub foo { bar }
use strict;
sub bar;
sub foo { bar };"abuse" was not the word I was looking for: I meant you're using Perl's syntactic freedom, and this trick does not work with PHP.
If you think that's "abusing" Perl 5 syntax for a useful effect, you should start reading up on Perl 6. Though you probably shouldn't if you have a weak heart.
[You're] abusing Perl's syntax for that syntactic-sugar...
Those are designed, documented, and tested features; they exist to do exactly this.
Those are designed, documented, and tested features; they exist to do exactly this.
... it is wrong design. Since obviously you are using the exceptions as control flow.
Exceptions aren't bugs, they're simply exceptional conditions. If you use them right they pose no problem but serve to make the code more legible.
I find it laughable that they’re arguing this from the "don’t abuse exceptions as control flow" angle considering that PHP 5.3 introduced goto.
Oh, great, another way for the rails nazies here at work to make fun of php... -_-U
PHP is like legos or loxblox, mmmkay? And I'm not saying legos aren't awesome, or that you can't build a house out of it. Absolutely you can.
Yeah, I know. But working on a wood statue with a humble knife should not be an excuse for the chainsaw guy to call you a dumb bastard for not be doing the statue with the chainsaw, "like proper men should do". Yes, the quoted phrase was actually heard on my office. Go figure...
( ...and I don't have anything against ruby. I'm learning rails. www.railsforzombies.com is great. In fact, my php is made on cakephp and lithium, which are pretty similar to rails... )
( ...and I don't have anything against ruby. I'm learning rails. www.railsforzombies.com is great. In fact, my php is made on cakephp and lithium, which are pretty similar to rails... )
Exceptions are control flow and nothing more. Any try/catch block could be rewritten with if/else checks on various error flags, assuming such flags are exposed. See C. Exceptions are just a clean way to write error handling and stack unwinding code without large amounts of if/else and return statements. Saying "finally" isn't necessary is like saying "foreach" isn't necessary when you have "while".
"Any try/catch block could be rewritten with if/else checks on various error flags"
Well, yes and no. Correctly writing your if flags to be polymorphic on the type of the exceptions is certainly possible but you're getting into the domain of things that a compiler really ought to be doing for you.
I've successfully made use of polymorphic exceptions, but I will freely concede I seem to be in the minority. Also I love having them being objects because then I also load the logic into them for presentation both to the human user and the developer which turns out to be really useful but also apparently a minority idea. Adding that to your if/else blocks would be insane.
Frankly, exceptions are badly underutilized, but one could say that about quite a lot of OO concepts, really. Many people understand the surface forms but manage to miss the point entirely. If that's all you've ever seen for exception handling I can understand why you wouldn't think it's very useful.
Well, yes and no. Correctly writing your if flags to be polymorphic on the type of the exceptions is certainly possible but you're getting into the domain of things that a compiler really ought to be doing for you.
I've successfully made use of polymorphic exceptions, but I will freely concede I seem to be in the minority. Also I love having them being objects because then I also load the logic into them for presentation both to the human user and the developer which turns out to be really useful but also apparently a minority idea. Adding that to your if/else blocks would be insane.
Frankly, exceptions are badly underutilized, but one could say that about quite a lot of OO concepts, really. Many people understand the surface forms but manage to miss the point entirely. If that's all you've ever seen for exception handling I can understand why you wouldn't think it's very useful.
Syntactic sugar would be the right term for this, I guess. I think everyone who has dealt in languages not having Try-Finally can recall a case or two where it would've felt smooth and tidy to have access to Finally - but never, ever a case where they absolutely required it. No one is having problems in C/++ because of this. No one is having problems in PHP, either.
And saying this will probably get me the flood of down votes, but this has always struck me as being something that is a language "requirement" only in people who have an itch in a hard-to-reach place in the engineering department of their brain - no offense meant. They need it for their sense of order, not for their software.
And saying this will probably get me the flood of down votes, but this has always struck me as being something that is a language "requirement" only in people who have an itch in a hard-to-reach place in the engineering department of their brain - no offense meant. They need it for their sense of order, not for their software.
Finally makes it much more easy, and much more readable, to do the right thing. Not having finally means duplicated code and harder to follow methods where resources have to be managed, and for most developers, this simply means resources are not managed properly at all.
C++ doesn't need finally because it has deterministic destructors, which are used to emulate finally clauses. In my opinion, destructors can cause less readable/predictable code than a proper finally block, but that might be matter of taste.
Comment from the language maintainer: The only difference is the second example does rethrow the exception. Though this is still possible (however much more to type) it is wrong design. Since obviously you are using the exceptions as control flow.
This seems quite strange. Finally is a construct to manage control flow, and it's essential to control flow during error conditions. He seems to prefer just swallowing a (potentially critical) exception. Either I'm misreading him, or I think he fails to understand the point of either finally, or exception handling in general.
C++ doesn't need finally because it has deterministic destructors, which are used to emulate finally clauses. In my opinion, destructors can cause less readable/predictable code than a proper finally block, but that might be matter of taste.
Comment from the language maintainer: The only difference is the second example does rethrow the exception. Though this is still possible (however much more to type) it is wrong design. Since obviously you are using the exceptions as control flow.
This seems quite strange. Finally is a construct to manage control flow, and it's essential to control flow during error conditions. He seems to prefer just swallowing a (potentially critical) exception. Either I'm misreading him, or I think he fails to understand the point of either finally, or exception handling in general.
"Finally makes it much more easy, and much more readable, to do the right thing."
I think this gets to the heart of what feels 'off' about PHP to me: this kind of passive-aggressiveness against "doing the right thing" seems built-in. Kind of like how in order to avoid XSS, PHP offers htmlspecialchars(), or to avoid SQL injection, mysql_real_escape_string() (I'm aware of PDO, but it seems few if any major projects use it).
I think this gets to the heart of what feels 'off' about PHP to me: this kind of passive-aggressiveness against "doing the right thing" seems built-in. Kind of like how in order to avoid XSS, PHP offers htmlspecialchars(), or to avoid SQL injection, mysql_real_escape_string() (I'm aware of PDO, but it seems few if any major projects use it).
> C++ doesn't need finally because it has deterministic destructors
PHP has deterministic destructors as well. Using them is how I get around the lack of finally -- destructors do the clean up.
PHP has deterministic destructors as well. Using them is how I get around the lack of finally -- destructors do the clean up.
Question: when are PHP's object destructors called ? I can see some issues with external resources if an object instance hangs around until it is garbage collected. PHP might not have an issue with this if it does GC for every page load, but other languages like the .NET languages can experience serious issues if you don't release external resources using a finally block, and rather rely on the destruction of the object to release them. In such a case, the destruction may take place a long time after the initial acquisition of the external resources.
My point is that object lifetime <> external resource usage duration in all cases.
My point is that object lifetime <> external resource usage duration in all cases.
> when are PHP's object destructors called ?
As soon as there are no more references to it. PHP is reference counted (with cycle detection). As soon as the variable containing an object goes out of scope, the destructor will be called.
The fact that Java/C# destructors aren't called immediately (and may not be called at all) is the primary reason that Java has the finally block (C++ doesn't) and why C# also has the using statement.
As soon as there are no more references to it. PHP is reference counted (with cycle detection). As soon as the variable containing an object goes out of scope, the destructor will be called.
The fact that Java/C# destructors aren't called immediately (and may not be called at all) is the primary reason that Java has the finally block (C++ doesn't) and why C# also has the using statement.
Thanks for the response. I knew that PHP was reference counted, but what I was asking (not particularly well) was more along the lines of: is it possible to have objects live longer than the scope of a single script ? IOW, is there a point at which the PHP runtime decides that it is going to collect/reclaim everything, similar to a process termination in the OS ? Or is it literally possible to implicitly allocate objects in a global fashion and have them stick around until the PHP runtime itself is terminated ? Thanks again.
When a single script terminates, all the memory is deallocated. Basically, as you said, it's just like process termination in the OS.
Well, in fact you could serialize/unserialize the objects and store them somewhere, making use of the "magic" functions __sleep() and __wakeup(), if I recall correctly. But yes, as soon as the web server ends the response or the script gets to the end, it's finished
Thanks. That's what I thought, but I'm fairly new to PHP, and wasn't entirely sure.
> No one is having problems in C/++ because of this.
No one is having problems with this in C because C doesn't have exceptions.
No one is having problems with this in C++ because C++ supports RAII via destructors which are guaranteed to run on stack unwind.
No one is having problems with this in C because C doesn't have exceptions.
No one is having problems with this in C++ because C++ supports RAII via destructors which are guaranteed to run on stack unwind.
You can do RAII in PHP via destructors as well. That's how I "get around" this problem.
So if I read that right, you don't need finally because you can unlock mysql tables when catching the exception? That's brilliant. Clearly as far as the PHP team is concerned, there is no other use for PHP than using it with MySQL.
The person who submitted the bug included an example of finally with MySQL, and the PHP guy was holding to that theme so that his response would be as clear as possible. So really, you should be blaming some random guy on the Internet for having no other use for PHP than using it with MySQL, which is more than likely true.
What irritates me about this thread is the sense of entitlement from people who file bugs.
If helly wants to say "there was a discussion about this on the internals list, and the decision was no" he doesn't have to justify anything more.
If they still care enough, they can dig up the internals thread and re-spark discussion.
If helly wants to say "there was a discussion about this on the internals list, and the decision was no" he doesn't have to justify anything more.
If they still care enough, they can dig up the internals thread and re-spark discussion.
One of the notes on the report is someone who did try to dig up the discussion and couldn't find it, only a bunch of people saying without reasons "we do not need finally". It seems polite to me for someone who knows when/where said discussion was to link to it.
A programming language is a tool and its syntax is its UI. PHP community doesn't get this. They never have. Just because you can empirically prove that a language doesn't need a feature, it doesn't mean you shouldn't add it if it's obvious that most developers would _enjoy_ using it.
The example is the wrong case. Unless you are using MyISAM tables (hint: 90%+ of the time you shouldn't), there's rarely a situation to LOCK TABLES as described.
Using transactions would make more sense:
Using transactions would make more sense:
try {
mysql_query("START TRANSACTION");
// ... do lots of queries here
mysql_query("COMMIT");
} catch(Exception $e) {
mysql_query("ROLLBACK");
}You left out the code where you acquire the database connection and need to release it before returning as well as propagate the success or failure of the operation.
Just like with C++ (which also doesn't have finally) you can use RAII techniques with PHP. Object destructors will get called when your object goes out of scope. I use this to clean up resources (mainly rollback transations) in the case of exceptions.
In fact, now with PHP 5.3 and closures one could emulate finally quite easily: just create an object that runs the closure on destruction and it will be called at the end of the block.
Finally would still, however, be a welcome addition to the language.
In fact, now with PHP 5.3 and closures one could emulate finally quite easily: just create an object that runs the closure on destruction and it will be called at the end of the block.
Finally would still, however, be a welcome addition to the language.
[deleted]
try{ some ifs ... return x ... more ifs ... throw ... return y }catch{ handle exceptions }finally{ do_something_finally() }
and
try{ some ifs ... return x ... more ifs ... throw ... return y }catch{ handle exceptions } do_something_finally()
I'm missing something, I'm not?