Edit report at https://bugs.php.net/bug.php?id=32100&edit=1
ID: 32100
Comment by: toplegocreator at hotmail dot com
Reported by: ceefour at gauldong dot net
Summary: Request 'finally' support for exceptions
Status: Closed
Type: Feature/Change Request
Package: Feature/Change Request
Operating System: *
PHP Version: 5.*
Block user comment: N
Private report: N
New Comment:
"Though this is still possible (however much more to type) it is wrong design.
Since obviously you are using the exceptions as control flow."
If exceptions should never be propagated up the stack to a block of code that
knows how to deal with them, why are exceptions there in the first place?
Exceptions ARE flow control. That's their reason for existing. If they
shouldn't be used that way, they shouldn't be included in the language.
Let me elaborate. An exception should occur any time when the current block
cannot successfully continue execution in the current state and has no direct
means (or shouldn't have any direct means because of good separation of
concerns) of informing the client of the problem. A finally clause, while not
strictly needed if code repetition is acceptable (and it isn't in my book), is
appropriate for ensuring that resources (like database connections, open files,
a printer, whatever) are released when fatal errors occur. Trying to deal with
the error as some kind of returned result all the way up the stack will just
make your code more difficult to read and maintain; an error should go all the
way up the stack until a piece of code that's responsible for output can
determine how to inform the client. That's how exceptions are supposed to be
used, and a finally clause makes it possible to properly and (fairly) reliably
release resources, which is also a best practice.
Previous Comments:
------------------------------------------------------------------------
[2012-04-19 20:00:39] simon at stienen dot name
RAII is an elegant solution for tidying up scopes reliably.
It is also possible in PHP to do RAII without writing one class per resource
type:
<?php
class ScopeGuard {
private $callback;
function __construct($callback) {
$this->callback = $callback;
}
function __destruct() {
if (is_callable($this->callback)) {
call_user_func($this->callback);
}
}
}
function do_something() {
mysql_query("LOCK TABLES mytable WRITE");
$guard = new ScopeGuard(function() {
mysql_query("UNLOCK TABLES");
});
try {
// ... do lots of queries here
}
}
?>
$guard will be destructed when leaving the do_something - either by throwing an
exception or by exiting the function normally.
HOWEVER: RAII in C++ (which neither employs nor needs a finally keyword) is
more subtle - or rather: Scopes are. In PHP you can define a variable within a
loop or a conditional block - and use it afterwards. In C++ you can't. A
variable defined inside a certain block will be destroyed once the block is
left. Consider the following example:
<?php
function do_something() {
if (foo) {
mysql_query("LOCK TABLES mytable WRITE");
$guard = new ScopeGuard(function() {
mysql_query("UNLOCK TABLES");
});
try {
// ... do lots of queries here
}
// *1*
}
do_something_else();
// *2*
}
?>
In C++, this would work as expected of a "finally" replacement and unlock the
tables at *1*, when the if scope closes. In PHP however, $guard will only be
destroyed when leaving the function at *2*. This can be fixed by manually
adding an unset($guard) at *1*, but this is inelegant and error prone.
So, while I have never needed finally, I think the way PHP works and is used
absolutely validates its introduction as a useful addition to the language. The
alternative would be to introduce C/++ style closed scopes, but those would
most likely not only break a lot of existing code, but the coders as well, as
they do not even remotely fit into the way PHP is written.
------------------------------------------------------------------------
[2012-04-12 15:42:21] matthias at die-legendaeren dot de
"Just going to say 'Me too!'? Don't clutter the database with that please !"
But this is the right place for a "me too": to prove that a statement from 12
years ago was shortsighted and in a "works for me" way, developers (as
customers)
who disagree have to group behind their request.
------------------------------------------------------------------------
[2012-04-11 21:21:33] gudjonj at gmail dot com
+1 for finally in PHP
------------------------------------------------------------------------
[2012-04-11 08:34:13] ravilov at gmail dot com
My two cents...
Here's an example of emulating "finally" in PHP without needing to duplicate
code.
$_ex = null;
AllocateSomeResource();
try {
DoSomeProcessing();
} catch (Exception $ex) {
$_ex = $ex;
}
DeallocateSomeResource();
if ($_ex != null) {
throw $_ex;
}
That said, I completely agree any current workaround/emulation/"solution" is
nothing but cumbersome and bug-prone, and that we shouldn't have to come up
with such creative ways to overcome what seems like a language design flaw. PHP
is a tool, it is supposed to work *with* us, not *against* us.
------------------------------------------------------------------------
[2012-04-03 13:08:00] andrew dot feller at gmail dot com
The demand for "finally" is a symptom of PHP not officially and explicitly
addressing supported solutions to managing resources. I cannot find anything
within PHP documentation to address this:
http://www.php.net/manual/en/language.oop5.decon.php
http://www.php.net/manual/en/faq.misc.php
So I recommend to move beyond inclusion of finalizers and start with educating
constituents because there is an opportunity to resolve this and hopefully
improve quality of work done by developers
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=32100
--
Edit this bug report at https://bugs.php.net/bug.php?id=32100&edit=1
