Bug #52412 [Com]: __autoload fails to throw exception when calling a static method on the class
Edit report at http://bugs.php.net/bug.php?id=52412edit=1
ID: 52412
Comment by: php dot net at phrozenbyte dot de
Reported by:madboyka at yahoo dot com
Summary:__autoload fails to throw exception when calling a
static method on the class
Status: Bogus
Type: Bug
Package:Scripting Engine problem
Operating System: *
PHP Version:5.3.3
Block user comment: N
Private report: N
New Comment:
I support this re-opening-request... Since 5.3 __autoload() is definitly
*not* the last line of defense for PHP to find a class definition.
That's simply wrong.
http://www.php.net/manual/en/language.oop5.autoload.php (Note #1 +
Example #3)
http://www.php.net/manual/en/language.oop5.changelog.php (#5)
Previous Comments:
[2011-02-19 23:06:12] michael at squiloople dot com
Here's a request to re-open the bug, for it is indeed a bug: exceptions
can be
thrown and caught if the method called is _not_ static, as documented,
but cannot
be thrown and caught if the method _is_ static (and where the class name
is not a
variable), which is both inconsistent and against the documentation. It
is
_unexpected_ behaviour.
[2011-02-16 15:31:49] madboyka at yahoo dot com
To: der...@php.net
I don't think you've read the documentation on autoloading yourself:
http://www.php.net/manual/en/language.oop5.autoload.php
The first note states that since PHP 5.3, you may throw an exception
from the autoload function (even if the class can be loaded) and catch
that exception without a problem. Examples #3 and #4 in the
documentation entry demonstrate this. This works when the autoload
function gets invoked when instantiating a class, but doesn't when you
make a static call on it. This behavior is not consistent.
Also, take a look at michael@...'s workaround, which unexpectedly works
great. And don't tell me that PHP behaves as expected.
I understand, that this is not a major bug, we all can live without a
fix, but at least mark it as to be fixed in the far future.
[2011-02-16 11:24:38] der...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
FWIW, this is expected. The __autoload() method is the last line of
defense for PHP to find a class definition. If it can't find it, PHP
bails out with a fatal error. If you throw an exception, you basically
abort this final chance, and thus gives PHP you that fatal can not find
class error. However, you can catch the exception in the __autoload()
method,
[2011-02-16 08:05:14] michael at squiloople dot com
There's a slight hack of a solution tested using PHP 5.3.5 and Windows
Vista:
use a variable as the class name:
function __autoload($class)
{
if (!include $class . '.php')
{
throw new Exception('Cannot autoload ' . $class);
}
}
$class = 'Application';
try
{
$class::start();
}
catch (Exception $e)
{
echo $e-getMessage();
}
// Outputs the exception as expected.
[2010-09-25 23:39:25] alex dot offshore at gmail dot com
Temporary solution.
Caveats and notices:
- The class actually WILL BE DEFINED ANYWAY;
- 'eval' usage;
- __callStatic used to avoid method not found error.
?php
function __autoload($className)
{
echo Want to load $className.\n;
// assuming we can not load class
// error handling code
{
eval('class ' . $className . ' { static function __callStatic($n,
$a) { return false; } }');
throw new Exception(Unable to load $className.);
}
}
try
{
//new MissingClass(); // works as expected
MissingClass::someFunction();
}
catch (Exception $e)
{
echo 'CAUGHT: ' . $e-getMessage(), \n;
}
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
http://bugs.php.net/bug.php?id=52412
--
Edit this bug report at http://bugs.php.net/bug.php?id=52412edit=1
Bug #52848 [Com]: Processing out-of-band data doesn't work
Edit report at http://bugs.php.net/bug.php?id=52848edit=1
ID: 52848
Comment by: php dot net at phrozenbyte dot de
Reported by:php dot net at phrozenbyte dot de
Summary:Processing out-of-band data doesn't work
Status: To be documented
Type: Bug
Package:Streams related
Operating System: Ubuntu 10.04 Lucid Lynx
PHP Version:5.3.3
Block user comment: N
New Comment:
This doesn't help. Maybe it's an issue in my software repository I
will fill a bug report on launchpad. Thanks for your help and patience!
Previous Comments:
[2010-09-17 00:06:22] cataphr...@php.net
Maybe this is a timing issue. Try to start the client only a few seconds
later.
[2010-09-17 00:05:20] cataphr...@php.net
I can't reproduce this on Debian Lenny:
0: init
0: select
16: $read contains: array(1) {
[0]=
resource(2) of type (stream)
}
16: $except contains: array(0) {
}
16: client connected
16: select
16: $read contains: array(0) {
}
16: $except contains: array(1) {
[0]=
resource(3) of type (stream)
}
16: oob-data: 'a'
16: select
26: $read contains: array(1) {
[0]=
resource(3) of type (stream)
}
26: $except contains: array(0) {
}
26: client disconnected
[2010-09-16 19:24:42] php dot net at phrozenbyte dot de
I keeped the server script and replaced the client script with yours.
The result:
number of $read sockets: 1
number of $except sockets: 1
There's definitly a issue... Keep the client and try the following
server script:
?php
$now = time();
$server = stream_socket_server('tcp://127.0.0.1:1234');
echo time()-$now.: init\n;
do {
$read = $write = $except = array();
$read[] = $server;
if(isset($client)) {
$read[] = $client;
$except[] = $client;
}
echo time()-$now.: select\n;
stream_select($read, $write, $except, null);
echo time()-$now.': $read contains: '; var_dump($read);
echo time()-$now.': $except contains: '; var_dump($except);
foreach($except as $sock) { // $sock === $client
echo time()-$now.: oob-data:
'.stream_socket_recvfrom($client, 1500,
STREAM_OOB).'\n;
}
foreach($read as $sock) {
if($sock === $server) {
$client = stream_socket_accept($server);
echo time()-$now.: client connected\n;
} else { // $sock === $client
if(feof($client)) {
echo time()-$now.: client disconnected\n;
break 2;
}
$data = stream_socket_recvfrom($client, 1500);
echo time()-$now.: data: '.$data.'\n;
}
}
} while(true);
?
The script returns the following (notice the time!):
0: init
0: select
0: $read contains: array(1) {
[0]=
resource(5) of type (stream)
}
0: $except contains: array(0) {
}
0: client connected
0: select
0: $read contains: array(1) {
[0]=
resource(6) of type (stream)
}
0: $except contains: array(1) {
[0]=
resource(6) of type (stream)
}
0: oob-data: 'a'
10: client disconnected
That's wrong! At the second call of stream_select() the $read array
shouldn't contain any socket, only the $except array does because
there's data to read. The time delay between 0: oob-data: 'a' and 10:
client disconnected is a result of recv()s blocking. stream_select()
shouldn't fill $read when there's no data to read. The client-side
disconnect affects nothing, that happens (as you can see) 10 seconds
later.
[2010-09-16 12:40:35] cataphr...@php.net
There's still no bug. Here's a portion of the strace on the server:
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3
setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
bind(3, {sa_family=AF_INET, sin_port=htons(1234),
sin_addr=inet_addr(127.0.0.1)}, 16) = 0
listen(3, 32) = 0
poll([{fd=3, events=POLLIN|POLLERR|POLLHUP}], 1, 25000) = 1 ([{fd=3,
revents=POLLIN}])
accept(3, {sa_family=AF_INET, sin_port=htons(42533),
sin_addr=inet_addr(127.0.0.1)}, [16]) = 4
select(5, [3 4], [], [4], NULL) = 2 (in [4]], except [4])
So you call see that the call to select() actually returned the socket
handle in both fd_set structures, as PHP reported.
The reason for returning the socket handle in readfs is that the
connection was closed on the client side. If you don't close the
connection, you get your expected result.
Keep the same code on the server and use
Bug #52848 [Com]: Processing out-of-band data doesn't work
Edit report at http://bugs.php.net/bug.php?id=52848edit=1
ID: 52848
Comment by: php dot net at phrozenbyte dot de
Reported by:php dot net at phrozenbyte dot de
Summary:Processing out-of-band data doesn't work
Status: To be documented
Type: Bug
Package:Streams related
Operating System: Ubuntu 10.04 Lucid Lynx
PHP Version:5.3.3
Block user comment: N
New Comment:
I keeped the server script and replaced the client script with yours.
The result:
number of $read sockets: 1
number of $except sockets: 1
There's definitly a issue... Keep the client and try the following
server script:
?php
$now = time();
$server = stream_socket_server('tcp://127.0.0.1:1234');
echo time()-$now.: init\n;
do {
$read = $write = $except = array();
$read[] = $server;
if(isset($client)) {
$read[] = $client;
$except[] = $client;
}
echo time()-$now.: select\n;
stream_select($read, $write, $except, null);
echo time()-$now.': $read contains: '; var_dump($read);
echo time()-$now.': $except contains: '; var_dump($except);
foreach($except as $sock) { // $sock === $client
echo time()-$now.: oob-data:
'.stream_socket_recvfrom($client, 1500,
STREAM_OOB).'\n;
}
foreach($read as $sock) {
if($sock === $server) {
$client = stream_socket_accept($server);
echo time()-$now.: client connected\n;
} else { // $sock === $client
if(feof($client)) {
echo time()-$now.: client disconnected\n;
break 2;
}
$data = stream_socket_recvfrom($client, 1500);
echo time()-$now.: data: '.$data.'\n;
}
}
} while(true);
?
The script returns the following (notice the time!):
0: init
0: select
0: $read contains: array(1) {
[0]=
resource(5) of type (stream)
}
0: $except contains: array(0) {
}
0: client connected
0: select
0: $read contains: array(1) {
[0]=
resource(6) of type (stream)
}
0: $except contains: array(1) {
[0]=
resource(6) of type (stream)
}
0: oob-data: 'a'
10: client disconnected
That's wrong! At the second call of stream_select() the $read array
shouldn't contain any socket, only the $except array does because
there's data to read. The time delay between 0: oob-data: 'a' and 10:
client disconnected is a result of recv()s blocking. stream_select()
shouldn't fill $read when there's no data to read. The client-side
disconnect affects nothing, that happens (as you can see) 10 seconds
later.
Previous Comments:
[2010-09-16 12:40:35] cataphr...@php.net
There's still no bug. Here's a portion of the strace on the server:
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3
setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
bind(3, {sa_family=AF_INET, sin_port=htons(1234),
sin_addr=inet_addr(127.0.0.1)}, 16) = 0
listen(3, 32) = 0
poll([{fd=3, events=POLLIN|POLLERR|POLLHUP}], 1, 25000) = 1 ([{fd=3,
revents=POLLIN}])
accept(3, {sa_family=AF_INET, sin_port=htons(42533),
sin_addr=inet_addr(127.0.0.1)}, [16]) = 4
select(5, [3 4], [], [4], NULL) = 2 (in [4]], except [4])
So you call see that the call to select() actually returned the socket
handle in both fd_set structures, as PHP reported.
The reason for returning the socket handle in readfs is that the
connection was closed on the client side. If you don't close the
connection, you get your expected result.
Keep the same code on the server and use this for the client:
?php
$socket = stream_socket_client('tcp://127.0.0.1:1234');
stream_socket_sendto($socket, 'a', STREAM_OOB);
sleep(10);
fclose($socket);
You now see:
number of $read sockets: 0
number of $except sockets: 1
[2010-09-16 04:43:44] php dot net at phrozenbyte dot de
Yes, I understand that.
The issue is in a more special case: When the client sends a single byte
(!) with OOB flag, the server will receive 2 recv calls - the first one
including the single byte with OOB flag and the second one is empty
which results in feof() = true.
That means: Even when you send only a single byte with OOB flag, in
which case you can't read non-OOB-data, stream_select() triggers that
you can read non-OOB-data. And this is a issue with php I think.
Client:
---
?php
$socket = stream_socket_client('tcp://127.0.0.1:1234');
stream_socket_sendto($socket, 'a', STREAM_OOB);
fclose($socket);
?
Server:
---
?php
$server = stream_socket_server
Bug #52848 [Com]: Processing out-of-band data doesn't work
Edit report at http://bugs.php.net/bug.php?id=52848edit=1
ID: 52848
Comment by: php dot net at phrozenbyte dot de
Reported by:php dot net at phrozenbyte dot de
Summary:Processing out-of-band data doesn't work
Status: To be documented
Type: Bug
Package:Streams related
Operating System: Ubuntu 10.04 Lucid Lynx
PHP Version:5.3.3
Block user comment: N
New Comment:
Ok, thanks. As cataphract at php dot net mentioned first there are
situations on which even that single byte isn't shown. I'm not able to
reproduce the bug, the only possibility is to repeat running my test
server and client. After some trys the script will result in
OOB-Data 1/2: ''
OOB-Data 2/2: ''
Data 1/2: '12345678'
Data 2/2: ''
Previous Comments:
[2010-09-15 16:15:20] cataphr...@php.net
It should be documented in stream_socket_sendto and
stream_socket_recvfrom, that OOB data can be only one byte long.
[2010-09-15 16:13:20] cataphr...@php.net
In Transmission Control Protocol (TCP), the OOB data block is always
one byte. Therefore, if you send multiple-byte OOB data, only the last
byte of the OOB data is retrieved. The remaining data is treated like
normal data.
See also http://support.microsoft.com/kb/830597
[2010-09-15 14:44:54] cataphr...@php.net
Sorry, correction: Windows presented the same behavior.
[2010-09-15 14:15:06] cataphr...@php.net
I can reproduce it in Linux.
In Windows, the server gets no data at all (the first
stream_socket_recvfrom keeps blocking indefinitely).
[2010-09-15 04:13:49] php dot net at phrozenbyte dot de
Description:
I'm not sure what's going wrong (stream_socket_sendto() or
stream_socket_recvfrom()) but proccessing out-of-band data doesn't work
correctly. Only the last byte is send as out-of-band data, all other
data is send as usally.
Test script:
---
Server:
?php
$server = stream_socket_server('tcp://127.0.0.1:1234');
$socket = stream_socket_accept($server);
echo OOB-Data 1/2: '.stream_socket_recvfrom($socket, 1500,
STREAM_OOB).'\n;
echo OOB-Data 2/2: '.stream_socket_recvfrom($socket, 1500,
STREAM_OOB).'\n;
echo Data 1/2: '.stream_socket_recvfrom($socket, 1500).'\n;
echo Data 2/2: '.stream_socket_recvfrom($socket, 1500).'\n;
fclose($socket);
fclose($server);
?
Client:
?php
$socket = stream_socket_client('tcp://127.0.0.1:1234');
stream_socket_sendto($socket, '123456789', STREAM_OOB);
fclose($socket);
?
Expected result:
OOB-Data 1/2: '123456789'
OOB-Data 2/2: ''
Data 1/2: ''
Data 2/2: ''
Actual result:
--
OOB-Data 1/2: '9'
OOB-Data 2/2: ''
Data 1/2: '12345678'
Data 2/2: ''
--
Edit this bug report at http://bugs.php.net/bug.php?id=52848edit=1
Bug #52848 [Com]: Processing out-of-band data doesn't work
Edit report at http://bugs.php.net/bug.php?id=52848edit=1 ID: 52848 Comment by: php dot net at phrozenbyte dot de Reported by:php dot net at phrozenbyte dot de Summary:Processing out-of-band data doesn't work Status: To be documented Type: Bug Package:Streams related Operating System: Ubuntu 10.04 Lucid Lynx PHP Version:5.3.3 Block user comment: N New Comment: When you're sending data out-of-band (one or more bytes make no difference) and the client socket is in $read and $except of stream_select() the socket will be available every time in both arrays. Previous Comments: [2010-09-15 20:41:18] php dot net at phrozenbyte dot de Ok, thanks. As cataphract at php dot net mentioned first there are situations on which even that single byte isn't shown. I'm not able to reproduce the bug, the only possibility is to repeat running my test server and client. After some trys the script will result in OOB-Data 1/2: '' OOB-Data 2/2: '' Data 1/2: '12345678' Data 2/2: '' [2010-09-15 16:15:20] cataphr...@php.net It should be documented in stream_socket_sendto and stream_socket_recvfrom, that OOB data can be only one byte long. [2010-09-15 16:13:20] cataphr...@php.net In Transmission Control Protocol (TCP), the OOB data block is always one byte. Therefore, if you send multiple-byte OOB data, only the last byte of the OOB data is retrieved. The remaining data is treated like normal data. See also http://support.microsoft.com/kb/830597 [2010-09-15 14:44:54] cataphr...@php.net Sorry, correction: Windows presented the same behavior. [2010-09-15 14:15:06] cataphr...@php.net I can reproduce it in Linux. In Windows, the server gets no data at all (the first stream_socket_recvfrom keeps blocking indefinitely). 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 http://bugs.php.net/bug.php?id=52848 -- Edit this bug report at http://bugs.php.net/bug.php?id=52848edit=1
Bug #52848 [Com]: Processing out-of-band data doesn't work
Edit report at http://bugs.php.net/bug.php?id=52848edit=1
ID: 52848
Comment by: php dot net at phrozenbyte dot de
Reported by:php dot net at phrozenbyte dot de
Summary:Processing out-of-band data doesn't work
Status: To be documented
Type: Bug
Package:Streams related
Operating System: Ubuntu 10.04 Lucid Lynx
PHP Version:5.3.3
Block user comment: N
New Comment:
Yes, I understand that.
The issue is in a more special case: When the client sends a single byte
(!) with OOB flag, the server will receive 2 recv calls - the first one
including the single byte with OOB flag and the second one is empty
which results in feof() = true.
That means: Even when you send only a single byte with OOB flag, in
which case you can't read non-OOB-data, stream_select() triggers that
you can read non-OOB-data. And this is a issue with php I think.
Client:
---
?php
$socket = stream_socket_client('tcp://127.0.0.1:1234');
stream_socket_sendto($socket, 'a', STREAM_OOB);
fclose($socket);
?
Server:
---
?php
$server = stream_socket_server('tcp://127.0.0.1:1234');
$socket = stream_socket_accept($server);
$read = array($server, $socket); $write = array(); $except =
array($socket);
stream_select($read, $write, $except, null);
echo 'number of $read sockets: '.count($read).\n;
echo 'number of $except sockets: '.count($except).\n;
?
Expected result:
---
number of $read sockets: 0
number of $except sockets: 1
Actual result:
---
number of $read sockets: 1
number of $except sockets: 1
Previous Comments:
[2010-09-16 02:06:58] srina...@php.net
few additional comments
on Linux/Solaris socket implementations, when you send with MSG_OOB
flags set, only the last byte is recvd. the subsequent recv call will
flush out the rest of the bytes.
for example, in your example,if you edit it like below you will notice
this more clearly:
client script
?php
$socket = stream_socket_client('tcp://127.0.0.1:1234');
stream_socket_sendto($socket, '123456789', STREAM_OOB);
fclose($socket);
?
server (with 2 recv calls even though client is sending only one send
call.)
?php
$server = stream_socket_server('tcp://127.0.0.1:1234');
stream_set_timeout($server, 180);
$socket = stream_socket_accept($server);
echo Data: '.stream_socket_recvfrom($socket, 100, STREAM_OOB).'\n;
echo Data: '.stream_socket_recvfrom($socket, 100).'\n;
?
Hope this clarifies
I don't think this is an issue with PHP.
[2010-09-15 22:17:16] php dot net at phrozenbyte dot de
When you're sending data out-of-band (one or more bytes make no
difference) and the client socket is in $read and $except of
stream_select() the socket will be available every time in both arrays.
[2010-09-15 20:41:18] php dot net at phrozenbyte dot de
Ok, thanks. As cataphract at php dot net mentioned first there are
situations on which even that single byte isn't shown. I'm not able to
reproduce the bug, the only possibility is to repeat running my test
server and client. After some trys the script will result in
OOB-Data 1/2: ''
OOB-Data 2/2: ''
Data 1/2: '12345678'
Data 2/2: ''
[2010-09-15 16:15:20] cataphr...@php.net
It should be documented in stream_socket_sendto and
stream_socket_recvfrom, that OOB data can be only one byte long.
[2010-09-15 16:13:20] cataphr...@php.net
In Transmission Control Protocol (TCP), the OOB data block is always
one byte. Therefore, if you send multiple-byte OOB data, only the last
byte of the OOB data is retrieved. The remaining data is treated like
normal data.
See also http://support.microsoft.com/kb/830597
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
http://bugs.php.net/bug.php?id=52848
--
Edit this bug report at http://bugs.php.net/bug.php?id=52848edit=1
[PHP-BUG] Bug #52848 [NEW]: Processing out-of-band data doesn't work
From:
Operating system: Ubuntu 10.04 Lucid Lynx
PHP version: 5.3.3
Package: Streams related
Bug Type: Bug
Bug description:Processing out-of-band data doesn't work
Description:
I'm not sure what's going wrong (stream_socket_sendto() or
stream_socket_recvfrom()) but proccessing out-of-band data doesn't work
correctly. Only the last byte is send as out-of-band data, all other data
is send as usally.
Test script:
---
Server:
?php
$server = stream_socket_server('tcp://127.0.0.1:1234');
$socket = stream_socket_accept($server);
echo OOB-Data 1/2: '.stream_socket_recvfrom($socket, 1500,
STREAM_OOB).'\n;
echo OOB-Data 2/2: '.stream_socket_recvfrom($socket, 1500,
STREAM_OOB).'\n;
echo Data 1/2: '.stream_socket_recvfrom($socket, 1500).'\n;
echo Data 2/2: '.stream_socket_recvfrom($socket, 1500).'\n;
fclose($socket);
fclose($server);
?
Client:
?php
$socket = stream_socket_client('tcp://127.0.0.1:1234');
stream_socket_sendto($socket, '123456789', STREAM_OOB);
fclose($socket);
?
Expected result:
OOB-Data 1/2: '123456789'
OOB-Data 2/2: ''
Data 1/2: ''
Data 2/2: ''
Actual result:
--
OOB-Data 1/2: '9'
OOB-Data 2/2: ''
Data 1/2: '12345678'
Data 2/2: ''
--
Edit bug report at http://bugs.php.net/bug.php?id=52848edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52848r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52848r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52848r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52848r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52848r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52848r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52848r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52848r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52848r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52848r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52848r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52848r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52848r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52848r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52848r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52848r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52848r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52848r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52848r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52848r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52848r=mysqlcfg
Bug #52412 [Com]: __autoload fails to throw exception when calling a static method on the class
Edit report at http://bugs.php.net/bug.php?id=52412edit=1
ID: 52412
Comment by: php dot net at phrozenbyte dot de
Reported by:madboyka at yahoo dot com
Summary:__autoload fails to throw exception when calling a
static method on the class
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: Windows
PHP Version:5.3.3
Block user comment: N
New Comment:
Same on Ubuntu 10.04 / Apache 2.2 and CLI mode
Test script:
---
?php
spl_autoload_register(
function($autoload) {
throw new Exception();
}
);
try {
Foo::bar();
} catch(Exception $e) {
echo Exception caught\n;
}
?
Expected result:
Exception caught
Actual result:
--
Fatal error: Class 'Foo' not found in /home/daniel/www/other/php-bug.php
on line 0
Previous Comments:
[2010-07-23 09:34:02] madboyka at yahoo dot com
Description:
I've tried to do the following:
1. Wrote and autoload method, that throws an exception.
3. Made a static call on a non-existing class within a try block.
Tried this on windows 7 / Apache 2.2 / PHP 5.3.3.
Test script:
---
?php
function __autoload($class_name) {
throw new Exception($class_name);
}
try {
Application::start();
// new Application(); works fine
} catch (Exception $ex) {
var_dump($ex);
}
Expected result:
The script should var_dump() an exception with the Message 'Application'
as it does when instantiating a class.
Actual result:
--
The script dies with Fatal error: Class 'Application' not found.
--
Edit this bug report at http://bugs.php.net/bug.php?id=52412edit=1
