|
|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[2017-08-09 15:05 UTC] nachms+php at gmail dot com
Description:
------------
Consider the attached code, it outputs:
The throw did not destruct
destructing
--------------
This is somewhat surprising at first, but is due to exceptions containing a backtrace of all function parameters keeping objects alive somewhat unintuitively.
This really means that to have sane destruction behavior with exception handling, one must always unset the Exception at the end of a catch. Which is usually fine...
However, if one needs to rethrow from an exception handler, this means objects that need to be destructed as early as possible are now long-lived through many nested levels. There is no built-in way in PHP to remove these handles from the exception's backtrace.
With the way PHP currently works, we've found that an exception to handle some occasional error could in turn generate a whole chain reaction of problems simply because objects are now living far outside their scope, holding onto resources they ideally should not.
We're not sure of the best solution here, but it would seem that in order to handle these kinds of cases, PHP needs to offer a way to catch exceptions without keeping handles to stack objects. Perhaps some other way to catch, or some way to tell Exceptions to drop object handles from their backtrace before further handling them.
Test script:
---------------
<?php
$destructed = false;
class c
{
function __destruct()
{
global $destructed;
$destructed = true;
echo 'destructing', "\n";
}
}
function thrower($c) { throw(new Exception('oops')); }
function test()
{
$c = new c();
thrower($c);
}
try { test(); }
catch(Exception $e)
{
echo 'The throw ', ($destructed ? 'destructed' : 'did not destruct'), "\n";
}
Expected result:
----------------
One would intuitively expect:
destructing
The throw destructed
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Sat May 03 03:01:31 2025 UTC |
I'm not familiar with the mailing list, but if you start a discussion there, I can try to join in. ---------------------- While I agree that serialization of exceptions can be very useful for keeping track of errors that occurred and other things, this aspect of holding onto objects can cause some really really bad issues. Take this example: foreach ($somethings as $something) { echo 'Processing ', $something, "\n"; try { do_something($something); } catch (Exception $e) { echo 'Error occurred with ', $something, "\n"; } } At first glance this code looks perfectly fine, right? But if somewhere inside do_something() there's an object controlling resources that ends up part of a call frame, no matter how nested, if there's something which ends up creating a cursor on a database or has an open network handle, and then encounters an error, that cursor or network handle will remain open till the next error occurs! No destructors will fire. Holding open a database cursor indefinitely can cause further database actions to go wrong. Leaving open a network handle may have security ramifications, or lead to file descriptor starvation. Correct code is actually: foreach ($somethings as $something) { echo 'Processing ', $something, "\n"; try { do_something($something); } catch (Exception $e) { echo 'Error occurred with ', $something, "\n"; unset($e); } } Without the unset, the Exception lives throughout the duration of the loop since PHP variables have function lifetime not block scope lifetime. The Exception will not die till the next error occurs and the Exception variable in the catch ($e) is overwritten. The Exception in turn keeps resources locked, and living far outside their scope, thereby breaking encapsulation. Typically you expect stack unwinding to enforce function lifetime, but with Exceptions, many variables not only have function lifetime but Exception lifetime! We ran into this issue the other day, where the lack of an unset had severe ramifications, and it took a team of our developers over 5 hours to track down the bug. I don't think it's the kind of thing any developer is expecting. We've since updated our PHP guidelines to always put an unset into exception handling code where the Exception is not then further used beyond. For cases where there's some master object keeping track of Exceptions for some reason, it's not actually safe for the loop to continue, because desctructors not firing to release managed resources prevents another iteration from working properly. Basically we discovered with PHP that Exception tracking + loops + resource objects that get passed around is a recipe for disaster, and there does not seem to be any viable solutions to do this in PHP as it currently works. This prevents us from using PHP for various long lived tasks. Typically you want exception handling to make error handling easier and prevent bugs. But it seems with PHP's designs, once you realize how it works, it can make error handling much harder and create all kinds of bugs if not dealt with properly.