Req #32100 [Com]: Request 'finally' support for exceptions
Edit report at http://bugs.php.net/bug.php?id=32100edit=1
ID: 32100
Comment by: torsten dot landmann at bauermedia 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
New Comment:
I also agree: 'finally' is needed. I really don't get why it has been
left out.
There is no elegant equivalent, especially so since rethrowing the
exception alters file and line number saved in the exception, so later
it's hard to find out where it originally came from.
Please offer finally. Don't worry, nobody will be forced to use it.
I definitely will.
thuejk showed very well how 'finally' helps with keeping your code
clean. Or vice versa: How the absence of it often causes the need to
copy and paste code (which is always a bad development pattern).
Previous Comments:
[2010-06-27 00:59:16] thuejk at gmail dot com
We've had long discussions and came to the only conclusion that we
don't need
that, for more search the mailing list archieves.
Where is that discussion? I haven't been able to find it. Only people
saying
that finally is utterly useless, without showing any signs that they
have
actually considered finally's uses.
As the other comments have said, sometimes some code inside a try will
allocate
a non-php ressource which need to be deallocated whether or not an
exception is
thrown. To avoid writing that code twice, you need it in finally.
Version without finally:
try {
allocate non-php resource
} catch ($ex) {
deallocate non-php resource
throw $ex;
}
deallocate non-php resource
Version with finally:
try {
allocate non-php resource
} finally {
deallocate non-php resource
}
The finally code is obviously better. And it is a completely
reasonable way to
code.
Sure you can emulate finally with more code, but so can a Turin Machine.
finally
is syntactic sugar which makes it easier to write maintainable programs.
[2010-06-16 20:54:10] orlandu96 at gmail dot com
are there any updates on this issue?
[2010-03-31 12:40:17] a dot e at inne dot pl
Could finally also mean that 'returns' will be executed after the
finally block
try{
some ifs
...
return x
...
more ifs
...
throw
...
return y
}catch{
handle exceptions
}finally{
No matter if there was exception or not
execute this bit before you leave the method.
For example if object has some state it might be necessary to
make sure its consistent at the end
}
In the case i have now at work i had to add method call before every
return and throw to make sure that my data will be set properly before
method ends.
Would that be a feature someone might like?
thanks
art
[2005-02-25 20:27:50] ceefour at gauldong dot net
I don't think the code is absolutely equivalent. And omitting the
rethrow statement gives up the whole notion of 'finally'.
Actually my code was trying to *emulate* finally. But it's not the right
thing to do. Finally should not even touch the Exception at all...
Finally doesn't even know there is an exception.
I have to agree that 'finally' is not _required_ by PHP, but not by
'we'. 'We' in this sense refers to 'all PHP developers' and that
includes me, and I _need_ (although not _require_) this functionality.
Almost the same as namespaces don't have to be in PHP but some people
feel the need for it. However namespaces are much harder to implement
yet I think finally is relatively straightforward since we can already
emulate it using try/catch, but with the quirks.
I don't think finally is a control flow block. By emulating finally
using try/catch, yes maybe, but we have no other choice. Finally is not
a control flow because why..? Finally has no idea whether it is inside
an Exception or not, and cannot handle it i.e. it's not able to
_control_ processing based on the state of Exception. In this sense
finally is unconditional, just like ordinary statements but they're also
executed when Exception occurs.
IMHO Java has no responsibility here, I think exceptions, try, catch,
finally, are fully the domain of Object Oriented [Design ] Programming.
Delphi, C++Builder, C++, etc. has it, not just Java.
And even if it does, 'design' is out of the scope of PHP. PHP is a
programming language, not a design tool. PHP isn't strictly procedural
and also isn't strictly object-oriented. It's just a matter of taste.
Be conservative with what you emit
[PHP-BUG] Bug #51182 [NEW]: PHP crashes: zend_mm_heap corrupted after array operation
From: Operating system: Ubuntu PHP version: 5.2.13 Package: Reproducible crash} Bug Type: Bug Bug description:PHP crashes: zend_mm_heap corrupted after array operation Description: We have a reproducible crash scenario but there are two problems with that: 1. PHP doesn't crash EVERY time. 2. We didn't manage to reproduce the problem with a simple script yet. It only happens in our Drupal-driven website with about 3000 files and a complex database. However we managed to isolate the problem to a single line in code, which, if it gets rewritten, fixes the problem. Because this line actually is a little weird and not good programming style anyways, it seems plausible to us that you will be able to comprehend the problem in PHP sourcecode if you look into it directly. This is what happens if PHP crashes in our scenario: 1. The page gets completely rendered and output is written to the output stream. 2. Shutdown functions are executed. 3. After executing the last statement of the last shutdown function PHP suddenly crashes. The output buffer is discarded. The visitor sees blank page. The Apache error log receives a line that reads zend_mm_heap corrupted The following is the line of code that seems to cause the problem. This line of code is executed long before any output data is written and long before shutdown functions get executed. It doesn't crash directly but only seems to trigger a future crash: $tax = current(taxonomy_node_get_terms($node)); ($node is an instance of stdClass, taxonomy_node_get_terms() returns an array.) It seems that PHP may choke on its memory management later on when this line has been executed before. Maybe there's a problem because the return value is used for writing although not being saved in a variable. -- Edit bug report at http://bugs.php.net/bug.php?id=51182edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51182r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51182r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51182r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51182r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51182r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51182r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51182r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51182r=needscript Try newer version: http://bugs.php.net/fix.php?id=51182r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51182r=support Expected behavior: http://bugs.php.net/fix.php?id=51182r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51182r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51182r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51182r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51182r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51182r=dst IIS Stability: http://bugs.php.net/fix.php?id=51182r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51182r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51182r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51182r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51182r=mysqlcfg
[PHP-BUG] Bug #51182 [Fbk-Opn]: PHP crashes: zend_mm_heap corrupted after array operation
Edit report at http://bugs.php.net/bug.php?id=51182edit=1 ID: 51182 User updated by: torsten dot landmann at bauermedia dot com Reported by: torsten dot landmann at bauermedia dot com Summary: PHP crashes: zend_mm_heap corrupted after array operation -Status: Feedback +Status: Open Type: Bug Package: Reproducible crash Operating System: Ubuntu PHP Version: 5.2.13 New Comment: We'd love to but we're sorry, as already mentioned above, we're unable provide this script. We've really, really tried to create something simple for you but we didn't succeed. At the moment we can only reproduce the problem with running our complete project. Rewriting the mentioned line of code helps but that's all we can tell you. If the above information doesn't help you with identifying why all this is happening, we'll probably have to watch this issue further and maybe get back to you at a later time. Thanks. Previous Comments: [2010-03-02 18:16:24] j...@php.net -Status: Open +Status: Feedback [2010-03-02 18:16:24] j...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with ?php and ends with ?, is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. [2010-03-02 12:31:00] torsten dot landmann at bauermedia dot com Description: We have a reproducible crash scenario but there are two problems with that: 1. PHP doesn't crash EVERY time. 2. We didn't manage to reproduce the problem with a simple script yet. It only happens in our Drupal-driven website with about 3000 files and a complex database. However we managed to isolate the problem to a single line in code, which, if it gets rewritten, fixes the problem. Because this line actually is a little weird and not good programming style anyways, it seems plausible to us that you will be able to comprehend the problem in PHP sourcecode if you look into it directly. This is what happens if PHP crashes in our scenario: 1. The page gets completely rendered and output is written to the output stream. 2. Shutdown functions are executed. 3. After executing the last statement of the last shutdown function PHP suddenly crashes. The output buffer is discarded. The visitor sees blank page. The Apache error log receives a line that reads zend_mm_heap corrupted The following is the line of code that seems to cause the problem. This line of code is executed long before any output data is written and long before shutdown functions get executed. It doesn't crash directly but only seems to trigger a future crash: $tax = current(taxonomy_node_get_terms($node)); ($node is an instance of stdClass, taxonomy_node_get_terms() returns an array.) It seems that PHP may choke on its memory management later on when this line has been executed before. Maybe there's a problem because the return value is used for writing although not being saved in a variable. -- Edit this bug report at http://bugs.php.net/bug.php?id=51182edit=1
#39913 [Csd]: Installer does not work on x64
ID: 39913 User updated by: torsten at vip dot cybercity dot dk Reported By: torsten at vip dot cybercity dot dk Status: Closed Bug Type: Unknown/Other Function Operating System: Windows XP Professional x64 PHP Version: 5.2.0 Assigned To: jmertic New Comment: OK, thanks for looking into this. I'll check out 5.2.1 once that gets out. Previous Comments: [2006-12-21 12:42:27] [EMAIL PROTECTED] Missing quotes fixed in CVS (Bug #39716). I cannot replicate the changing install path on Windows XP Professional ( non-x64 ). I don't have an x64 bit version to test on, but it sounds like something specific to that version. It seems the error message you get is from PHP thinking it's getting installed in one place, but Windows thinking another. Changing the extension_dir directive to the correct path should fix it. mbstring is automatically installed when choosing to install exif currently. [2006-12-20 21:55:50] judas dot iscariote at gmail dot com mbstring extension is required by exif, see more information here: http://php.net/exif if so, there is no zend_module_dep defined on exif, so the user can be hinted on the logs.. Cannot load module exif because required module mbstring is not loaded [2006-12-20 21:29:01] [EMAIL PROTECTED] mbstring extension is required by exif, see more information here: http://php.net/exif [2006-12-20 21:13:00] torsten at vip dot cybercity dot dk Description: When installing on x64, the default install path is \Program Files (x86)\PHP. After installation, PHP fails with a syntax error because the value of extension_dir is not quoted. Uninstall and reinstall, being careful to select D:\Program Files\PHP as install path. When you get to the Choose Items to Install screen, the path still appears as \Program Files (x86)\PHP. Click Browse, navigate to \Program Files\PHP. The dialog still shows the (x86) path, and indeed the installation is performed to that path. Moved installation to desired path, hacked the registry at HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\PHP\InstallDir. When invoking php.exe from the command line, I get PHP Warning: PHP Startup: Unable to load dynamic library 'D:\Program Files\PHP\ ext\php_exif.dll' - The specified module could not be found. in Unknown on line 0 etc., although the file is there. -- Edit this bug report at http://bugs.php.net/?id=39913edit=1
#39913 [NEW]: Installer does not work on x64
From: torsten at vip dot cybercity dot dk Operating system: Windows XP Professional x64 PHP version: 5.2.0 PHP Bug Type: *General Issues Bug description: Installer does not work on x64 Description: When installing on x64, the default install path is \Program Files (x86)\PHP. After installation, PHP fails with a syntax error because the value of extension_dir is not quoted. Uninstall and reinstall, being careful to select D:\Program Files\PHP as install path. When you get to the Choose Items to Install screen, the path still appears as \Program Files (x86)\PHP. Click Browse, navigate to \Program Files\PHP. The dialog still shows the (x86) path, and indeed the installation is performed to that path. Moved installation to desired path, hacked the registry at HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\PHP\InstallDir. When invoking php.exe from the command line, I get PHP Warning: PHP Startup: Unable to load dynamic library 'D:\Program Files\PHP\ ext\php_exif.dll' - The specified module could not be found. in Unknown on line 0 etc., although the file is there. -- Edit bug report at http://bugs.php.net/?id=39913edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39913r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39913r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39913r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39913r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39913r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39913r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39913r=needscript Try newer version:http://bugs.php.net/fix.php?id=39913r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39913r=support Expected behavior:http://bugs.php.net/fix.php?id=39913r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39913r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39913r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39913r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39913r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39913r=dst IIS Stability:http://bugs.php.net/fix.php?id=39913r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39913r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39913r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39913r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39913r=mysqlcfg
#14484 [Com]: apache2 has not loaded php module
ID: 14484 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Apache2 related Operating System: Linux PHP Version: 4.1.0 New Comment: This problem is related to mod_perl, at leased on my server. as soon I enable mod_perl/1.99_07-dev Perl/v5.8.0 DAV/2 per httpd.conf php drops out. there must be a problem whith mod_perl and I just try to figure this out at the moment Previous Comments: [2002-01-23 11:10:32] [EMAIL PROTECTED] be careful the configuration change for Apache 2 you must use filter ! watch README from Apache2filter http://cvs.php.net/co.php/php4/sapi/apache2filter/README?r=1.8 you must replace : LoadModule php4_module modules/libphp4.so AddType application/x-httpd-php .php By LoadModule php4_module modules/libphp4.so Files *.php SetOutputFilter PHP SetInputFilter PHP /Files [2002-01-18 09:02:27] [EMAIL PROTECTED] I have exactly the same problem with php 4.1.1 with a lot simpler configure line. every compiles well but apache 2 start without loading the module [2002-01-15 14:00:17] [EMAIL PROTECTED] I have a same problem - Apache 2.0.28 + php4.1.1, linux kernel 2.4.10. [2001-12-13 07:22:54] [EMAIL PROTECTED] apache-2.0.28 php-4.1 - configuration line: configure --prefix=/opt --with-apxs2=/opt/apache2/bin/apxs --with-config-file-path=/opt/apache2/bin/conf --with-zlib-dir=/usr --with-zlib=/usr --enable-bcmath --with-bz2=/usr --enable-calendar --with-curl=/usr --with-gdbm --enable-dbase --enable-dbx --enable-dio --with-dom=/usr --enable-filepro --enable-ftp --with-gd=/usr --enable-gd-native-ttf --with-jpeg-dir=/usr --with-png-dir=/usr --with-ttf=/usr --with-t1lib=/usr --with-gettext=/usr --with-gmp --with-imap=/usr --with-ldap=/usr --with-mysql=/usr --with-unixODBC=/usr --enable-overload --with-pdflib=/usr/local --with-jpeg-dir=/usr --with-png-dir=/usr --with-tiff-dir=/usr --enable-sockets --enable-sysvsem --enable-sysvshm --enable-wddx --with-expat-dir=/usr --enable-xslt --with-xslt-sablot --with-expat-dir=/usr --enable-yp in httpd.conf: LoadModule php4_module modules/libphp4.so AddType application/x-httpd-php .php AddType application/x-httpd-php-source .phps if I run apache, the PHP module isn't loaded (server-info, server-status) -- Edit this bug report at http://bugs.php.net/?id=14484edit=1
Bug #16846: upload_max_filesize
From: [EMAIL PROTECTED] Operating system: IBM AIX 4.3.3 PHP version: 4.2.0 PHP Bug Type: *General Issues Bug description: upload_max_filesize It is not possible to increase the value for upload_max_filesize in php.ini to a value greater than 99 Bytes. Uploads with more them 10 MB doesn't work -- Edit bug report at http://bugs.php.net/?id=16846edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16846r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16846r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16846r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16846r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16846r=support Expected behavior: http://bugs.php.net/fix.php?id=16846r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16846r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16846r=submittedtwice
