#42438 [Fbk-Opn]: require require_once include include_once
ID: 42438 User updated by: perching_eagle at yahoo dot com Reported By: perching_eagle at yahoo dot com -Status: Feedback +Status: Open Bug Type: Scripting Engine problem Operating System: windows xp PHP Version: 5.2.3 New Comment: i guess i have to give up, if it works on linux then i will eventually have to make the transition to linux. i did try your last suggestion and it didn't work, but i will try it a few more times and then if my problem remains unsolved, i will switch to linux earlier than i had planned. and you may close this thread. thanks for your help. Previous Comments: [2007-08-30 09:46:17] [EMAIL PROTECTED] When you installed the snapshot, did you first shutdown whatever webserver you use and delete (!!) all old installed PHP related dlls/executables BEFORE you installed the snapshot version?? I can't reproduce this on Windows XP (yes, I have that..) nor on Linux (preferred OS). I suspect it's simply bad installation. [2007-08-30 06:01:25] perching_eagle at yahoo dot com one more thing i went to google translate to check what language was being dumped on my screen, and it was only the chinese to english translator that was able to decipher it, the words were meaningless but i wonder why. i hope someone can get to the bottom of this, the only solution i have right now is to manually copy all the files i would have included with the include or require directives, into one file for each class definition. the include,require,require_once,include_once all worked for non-object oriented programs. whenever it encountered the $this- operator in my code, especially in the constructor (just like the code in my first post), it dumps everything else after the $this- operator on my screen. [2007-08-30 02:17:15] perching_eagle at yahoo dot com not loading mbstrings didn't change anything, versions prior to 5.2.3 work well with no problem at all. i guess anyone that still uses a microsoft os like xp, can comfirm my complaint. well thanks jani for your help. if you have access to windows xp with php 5.2.3 installed on it, you may be able to figure out what the problem is. till then bye.. [2007-08-28 21:42:01] [EMAIL PROTECTED] Well, do you get readable error messages when you don't load mbstring? (this is getting quite boring..) [2007-08-28 18:57:35] perching_eagle at yahoo dot com i followed your advice, set display_errors to On and error_reporting to E_ALL, it didn't do much help but when i set the error_reporting to E_ALL E_STRICT the japanese characters disappeared from the output of my code when using a php editor (i use php designer), however nothing changed when i tried display my output on a browser window using apache httpd. i also noticed some comments or non-directives in the php ini file, that were not properly commented with ; and correcting them still didn't help. i also think that in the window edition of php 5.2.3 download, mb_string language was set to japanese by default, even for english language speakers, and those japanese characters dumped on the output screen from my code, could be error messages automatically translated into japanese. 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/42438 -- Edit this bug report at http://bugs.php.net/?id=42438edit=1
#42438 [Opn]: require require_once include include_once
ID: 42438 User updated by: perching_eagle at yahoo dot com Reported By: perching_eagle at yahoo dot com Status: Open Bug Type: Scripting Engine problem Operating System: windows xp PHP Version: 5.2.3 New Comment: one more thing i went to google translate to check what language was being dumped on my screen, and it was only the chinese to english translator that was able to decipher it, the words were meaningless but i wonder why. i hope someone can get to the bottom of this, the only solution i have right now is to manually copy all the files i would have included with the include or require directives, into one file for each class definition. the include,require,require_once,include_once all worked for non-object oriented programs. whenever it encountered the $this- operator in my code, especially in the constructor (just like the code in my first post), it dumps everything else after the $this- operator on my screen. Previous Comments: [2007-08-30 02:17:15] perching_eagle at yahoo dot com not loading mbstrings didn't change anything, versions prior to 5.2.3 work well with no problem at all. i guess anyone that still uses a microsoft os like xp, can comfirm my complaint. well thanks jani for your help. if you have access to windows xp with php 5.2.3 installed on it, you may be able to figure out what the problem is. till then bye.. [2007-08-28 21:42:01] [EMAIL PROTECTED] Well, do you get readable error messages when you don't load mbstring? (this is getting quite boring..) [2007-08-28 18:57:35] perching_eagle at yahoo dot com i followed your advice, set display_errors to On and error_reporting to E_ALL, it didn't do much help but when i set the error_reporting to E_ALL E_STRICT the japanese characters disappeared from the output of my code when using a php editor (i use php designer), however nothing changed when i tried display my output on a browser window using apache httpd. i also noticed some comments or non-directives in the php ini file, that were not properly commented with ; and correcting them still didn't help. i also think that in the window edition of php 5.2.3 download, mb_string language was set to japanese by default, even for english language speakers, and those japanese characters dumped on the output screen from my code, could be error messages automatically translated into japanese. [2007-08-28 11:19:54] [EMAIL PROTECTED] Try rewriting those files of yours from scratch and set error_reporting to E_ALL and display_errors=On in your php.ini.. [2007-08-28 11:18:33] [EMAIL PROTECTED] Perhaps the reason it works for me is that I don't bother using Windows but a working OS instead. Linux. :) 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/42438 -- Edit this bug report at http://bugs.php.net/?id=42438edit=1
#42438 [Fbk-Opn]: require require_once include include_once
ID: 42438 User updated by: perching_eagle at yahoo dot com Reported By: perching_eagle at yahoo dot com -Status: Feedback +Status: Open Bug Type: Scripting Engine problem Operating System: windows xp PHP Version: 5.2.3 New Comment: not loading mbstrings didn't change anything, versions prior to 5.2.3 work well with no problem at all. i guess anyone that still uses a microsoft os like xp, can comfirm my complaint. well thanks jani for your help. if you have access to windows xp with php 5.2.3 installed on it, you may be able to figure out what the problem is. till then bye.. Previous Comments: [2007-08-28 21:42:01] [EMAIL PROTECTED] Well, do you get readable error messages when you don't load mbstring? (this is getting quite boring..) [2007-08-28 18:57:35] perching_eagle at yahoo dot com i followed your advice, set display_errors to On and error_reporting to E_ALL, it didn't do much help but when i set the error_reporting to E_ALL E_STRICT the japanese characters disappeared from the output of my code when using a php editor (i use php designer), however nothing changed when i tried display my output on a browser window using apache httpd. i also noticed some comments or non-directives in the php ini file, that were not properly commented with ; and correcting them still didn't help. i also think that in the window edition of php 5.2.3 download, mb_string language was set to japanese by default, even for english language speakers, and those japanese characters dumped on the output screen from my code, could be error messages automatically translated into japanese. [2007-08-28 11:19:54] [EMAIL PROTECTED] Try rewriting those files of yours from scratch and set error_reporting to E_ALL and display_errors=On in your php.ini.. [2007-08-28 11:18:33] [EMAIL PROTECTED] Perhaps the reason it works for me is that I don't bother using Windows but a working OS instead. Linux. :) [2007-08-28 00:41:16] perching_eagle at yahoo dot com i tried the new extension in your post and it didn't help. one question? did you try saving the two classes in seperate files? that is when the problem arises, i even notice that by importing dummy php files created similar results, the characters that are dumped on the screen looks a lot like japanese characters. 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/42438 -- Edit this bug report at http://bugs.php.net/?id=42438edit=1
#42438 [Fbk-Opn]: require require_once include include_once
ID: 42438 User updated by: perching_eagle at yahoo dot com Reported By: perching_eagle at yahoo dot com -Status: Feedback +Status: Open Bug Type: Scripting Engine problem Operating System: windows xp PHP Version: 5.2.3 New Comment: i followed your advice, set display_errors to On and error_reporting to E_ALL, it didn't do much help but when i set the error_reporting to E_ALL E_STRICT the japanese characters disappeared from the output of my code when using a php editor (i use php designer), however nothing changed when i tried display my output on a browser window using apache httpd. i also noticed some comments or non-directives in the php ini file, that were not properly commented with ; and correcting them still didn't help. i also think that in the window edition of php 5.2.3 download, mb_string language was set to japanese by default, even for english language speakers, and those japanese characters dumped on the output screen from my code, could be error messages automatically translated into japanese. Previous Comments: [2007-08-28 11:19:54] [EMAIL PROTECTED] Try rewriting those files of yours from scratch and set error_reporting to E_ALL and display_errors=On in your php.ini.. [2007-08-28 11:18:33] [EMAIL PROTECTED] Perhaps the reason it works for me is that I don't bother using Windows but a working OS instead. Linux. :) [2007-08-28 00:41:16] perching_eagle at yahoo dot com i tried the new extension in your post and it didn't help. one question? did you try saving the two classes in seperate files? that is when the problem arises, i even notice that by importing dummy php files created similar results, the characters that are dumped on the screen looks a lot like japanese characters. [2007-08-27 08:43:52] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi I can't reproduce this. (I get the expected result..) [2007-08-27 08:41:46] perching_eagle at yahoo dot com actual output: surname=$name; } } ?#17930;#29793;#27745;#25888;#29298;#29295;#27715;#29537;#8307;#17959;#29793;#25960;#10098;#28192;#29807;#26144;#30063;#25710;#26912;#8302;#14915;#17500;#25455;#28021;#28261;#29556;#24864;#25710;#21280;#29797;#26996;#26478;#23667;#28537;#26989;#29472;#29551;#28257;#24953;#17500;#29541;#29803;#28783;#30556;#29295;#8299;#25954;#25454;#23656;#26736;#8304;#26982;#25964;#23667;#28798;#28776;#25956;#26995;#28263;#29285;#28511;#29813;#30064;#24436;#28020;#11888;#26736;#8304;#28271;#27680;#28265;#8293;#2611; 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/42438 -- Edit this bug report at http://bugs.php.net/?id=42438edit=1
#42438 [NEW]: require require_once include include_once
From: perching_eagle at yahoo dot com
Operating system: windows xp
PHP version: 5.2.3
PHP Bug Type: Scripting Engine problem
Bug description: require require_once include include_once
Description:
the require, require_once, include, include_once operators produce
unexpected results when used to import files in php v5.2.3, this problem
didn't exist in the previous version i was using.
two files contain two different classes that have a parent and child
relationship. if both classes are on the same file, the scripting engine
outputs the expected result. however, if they are kept in separate files
and any of the four import operators are used, the scripting engine dumps
jargons on the output screen.
pls. try out the example before closing, suspending or the changing the
status of this complaint to bogus. Bug #41855 is the same problem as this
one, but someone rushed to conclusions without testing and proclaimed it
bogus.
Reproduce code:
---
?php // parent.php
class Father{
public $surname;
public function __construct($name){
$this-surname=$name; }
}
?
//
//separate files
//
?php // child.php
include_once(parent.php);
class Son extends Father{
public $name;
public function __construct($first,$last){
parent::__construct($last);
$this-name=$first;
}
}
$boy=new Son(john,doe);
print $boy-name;
print br;
print $boy-surname;
?
Expected result:
john
doe
Actual result:
--
surname=$name; } }
?#17930;#29793;#27745;#25888;#29298;#29295;#27715;#29537;#8307;#17959;#29793;#25960;#10098;#28192;#29807;#26144;#30063;#25710;#26912;#8302;#14915;#17500;#25455;#28021;#28261;#29556;#24864;#25710;#21280;#29797;#26996;#26478;#23667;#28537;#26989;#29472;#29551;#28257;#24953;#17500;#29541;#29803;#28783;#30556;#29295;#8299;#25954;#25454;#23656;#26736;#8304;#26982;#25964;#23667;#28798;#28776;#25956;#26995;#28263;#29285;#28511;#29813;#30064;#24436;#28020;#11888;#26736;#8304;#28271;#27680;#28265;#8293;#2611;
--
Edit bug report at http://bugs.php.net/?id=42438edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42438r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42438r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42438r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42438r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42438r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42438r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42438r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42438r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42438r=support
Expected behavior:http://bugs.php.net/fix.php?id=42438r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42438r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42438r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42438r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42438r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42438r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42438r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42438r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42438r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42438r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42438r=mysqlcfg
#42438 [Opn]: require require_once include include_once
ID: 42438
User updated by: perching_eagle at yahoo dot com
Reported By: perching_eagle at yahoo dot com
Status: Open
Bug Type: Scripting Engine problem
Operating System: windows xp
PHP Version: 5.2.3
New Comment:
actual output:
surname=$name; } }
?#17930;#29793;#27745;#25888;#29298;#29295;#27715;#29537;#8307;#17959;#29793;#25960;#10098;#28192;#29807;#26144;#30063;#25710;#26912;#8302;#14915;#17500;#25455;#28021;#28261;#29556;#24864;#25710;#21280;#29797;#26996;#26478;#23667;#28537;#26989;#29472;#29551;#28257;#24953;#17500;#29541;#29803;#28783;#30556;#29295;#8299;#25954;#25454;#23656;#26736;#8304;#26982;#25964;#23667;#28798;#28776;#25956;#26995;#28263;#29285;#28511;#29813;#30064;#24436;#28020;#11888;#26736;#8304;#28271;#27680;#28265;#8293;#2611;
Previous Comments:
[2007-08-27 08:40:23] perching_eagle at yahoo dot com
Description:
the require, require_once, include, include_once operators produce
unexpected results when used to import files in php v5.2.3, this problem
didn't exist in the previous version i was using.
two files contain two different classes that have a parent and child
relationship. if both classes are on the same file, the scripting engine
outputs the expected result. however, if they are kept in separate
files and any of the four import operators are used, the scripting
engine dumps jargons on the output screen.
pls. try out the example before closing, suspending or the changing the
status of this complaint to bogus. Bug #41855 is the same problem as
this one, but someone rushed to conclusions without testing and
proclaimed it bogus.
Reproduce code:
---
?php // parent.php
class Father{
public $surname;
public function __construct($name){
$this-surname=$name; }
}
?
//
//separate files
//
?php // child.php
include_once(parent.php);
class Son extends Father{
public $name;
public function __construct($first,$last){
parent::__construct($last);
$this-name=$first;
}
}
$boy=new Son(john,doe);
print $boy-name;
print br;
print $boy-surname;
?
Expected result:
john
doe
Actual result:
--
surname=$name; } }
?#17930;#29793;#27745;#25888;#29298;#29295;#27715;#29537;#8307;#17959;#29793;#25960;#10098;#28192;#29807;#26144;#30063;#25710;#26912;#8302;#14915;#17500;#25455;#28021;#28261;#29556;#24864;#25710;#21280;#29797;#26996;#26478;#23667;#28537;#26989;#29472;#29551;#28257;#24953;#17500;#29541;#29803;#28783;#30556;#29295;#8299;#25954;#25454;#23656;#26736;#8304;#26982;#25964;#23667;#28798;#28776;#25956;#26995;#28263;#29285;#28511;#29813;#30064;#24436;#28020;#11888;#26736;#8304;#28271;#27680;#28265;#8293;#2611;
--
Edit this bug report at http://bugs.php.net/?id=42438edit=1
#42438 [Fbk-Opn]: require require_once include include_once
ID: 42438
User updated by: perching_eagle at yahoo dot com
Reported By: perching_eagle at yahoo dot com
-Status: Feedback
+Status: Open
Bug Type: Scripting Engine problem
Operating System: windows xp
PHP Version: 5.2.3
New Comment:
i tried the new extension in your post and it didn't help.
one question?
did you try saving the two classes in seperate files?
that is when the problem arises, i even notice that by importing dummy
php files created similar results, the characters that are dumped on the
screen looks a lot like japanese characters.
Previous Comments:
[2007-08-27 08:43:52] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.2-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.2-win32-installer-latest.msi
I can't reproduce this. (I get the expected result..)
[2007-08-27 08:41:46] perching_eagle at yahoo dot com
actual output:
surname=$name; } }
?#17930;#29793;#27745;#25888;#29298;#29295;#27715;#29537;#8307;#17959;#29793;#25960;#10098;#28192;#29807;#26144;#30063;#25710;#26912;#8302;#14915;#17500;#25455;#28021;#28261;#29556;#24864;#25710;#21280;#29797;#26996;#26478;#23667;#28537;#26989;#29472;#29551;#28257;#24953;#17500;#29541;#29803;#28783;#30556;#29295;#8299;#25954;#25454;#23656;#26736;#8304;#26982;#25964;#23667;#28798;#28776;#25956;#26995;#28263;#29285;#28511;#29813;#30064;#24436;#28020;#11888;#26736;#8304;#28271;#27680;#28265;#8293;#2611;
[2007-08-27 08:40:23] perching_eagle at yahoo dot com
Description:
the require, require_once, include, include_once operators produce
unexpected results when used to import files in php v5.2.3, this problem
didn't exist in the previous version i was using.
two files contain two different classes that have a parent and child
relationship. if both classes are on the same file, the scripting engine
outputs the expected result. however, if they are kept in separate
files and any of the four import operators are used, the scripting
engine dumps jargons on the output screen.
pls. try out the example before closing, suspending or the changing the
status of this complaint to bogus. Bug #41855 is the same problem as
this one, but someone rushed to conclusions without testing and
proclaimed it bogus.
Reproduce code:
---
?php // parent.php
class Father{
public $surname;
public function __construct($name){
$this-surname=$name; }
}
?
//
//separate files
//
?php // child.php
include_once(parent.php);
class Son extends Father{
public $name;
public function __construct($first,$last){
parent::__construct($last);
$this-name=$first;
}
}
$boy=new Son(john,doe);
print $boy-name;
print br;
print $boy-surname;
?
Expected result:
john
doe
Actual result:
--
surname=$name; } }
?#17930;#29793;#27745;#25888;#29298;#29295;#27715;#29537;#8307;#17959;#29793;#25960;#10098;#28192;#29807;#26144;#30063;#25710;#26912;#8302;#14915;#17500;#25455;#28021;#28261;#29556;#24864;#25710;#21280;#29797;#26996;#26478;#23667;#28537;#26989;#29472;#29551;#28257;#24953;#17500;#29541;#29803;#28783;#30556;#29295;#8299;#25954;#25454;#23656;#26736;#8304;#26982;#25964;#23667;#28798;#28776;#25956;#26995;#28263;#29285;#28511;#29813;#30064;#24436;#28020;#11888;#26736;#8304;#28271;#27680;#28265;#8293;#2611;
--
Edit this bug report at http://bugs.php.net/?id=42438edit=1
#41012 [WFx]: exception handling
ID: 41012
User updated by: perching_eagle at yahoo dot com
Reported By: perching_eagle at yahoo dot com
Status: Wont fix
Bug Type: *Compile Issues
Operating System: *
PHP Version: *
New Comment:
to [EMAIL PROTECTED], thank you for your reasonable explanation.
Previous Comments:
[2007-04-10 05:19:01] [EMAIL PROTECTED]
Even though exceptions might be normalities in java and other languages
they keep having anexceptional role in PHP and stay theway they are. In
fact PHP is not a pure OO based language and needs to be able to deal
with its core errors in a non object oriented way. Further more PHP is
not perectly designed for applications have long run times but for web
share nothing web applications where the runtime depends on the time a
script needs to finish a request. For that reason a core error simply
needs to be logged rather than having a control mechanism that
reinitializes whatever should be running.
[2007-04-10 02:46:01] perching_eagle at yahoo dot com
correction=
for the first line of the python code in the post before this one.
# add qoutes to the parameter in the function 'input()'
num=input(enter a number, do not enter zero:)
the c programming language and other procedural languages can catch
errors just like object oriented laguages that use exceptions, if the
try keyword cannot force the compiler to overlook errors, then you
have to use an if statement, just like in c and actually write more
code. but if the try can suppress errors, you don't have to include
if statements and the throw keyword, you just write catch
statements that can catch each exception and error at runtime, and then
you can continue you code without stopping it or allow the program to
stop after sending a customized message on your site, rather than have
your site or program crash. you just explicitly throw an exception that
closes the program, after sending a customized message for fatal errors
simple.
**
to [EMAIL PROTECTED], a zero division error is an exception, it is not a
fatal error, fatal errors require that you reset the program.they are
errors that should not be caught such as linkage errors and thread death
errors and some machine errors. the program should be allowed to end
gracefully but could still catch them if you wish.
[2007-04-10 02:19:36] perching_eagle at yahoo dot com
well the logic behind exceptions is to help you handle ALL types of
errors and i will show you a similar example in python.
python code:
num=input('enter a number, do not enter zero:)
try:
print 34/int(num)
except ZeroDivisionError:
print error,you entered zero
(if you enter 2) output: 17
(if you enter 0) output: error, you entered zero
#java does exactly the same thing.
simple code, i didn't have to explicitly throw any exception (using the
throw keyword) or include an if statement. this obeys the rule of keep
things simple, and the try keyword actually does something, as opposed
to being a mere decoration as it is now in PHP.
[2007-04-08 15:11:42] [EMAIL PROTECTED]
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
Fatal errors are not exceptions and therefor try {} does nothing to
catch them.
[2007-04-06 21:00:29] perching_eagle at yahoo dot com
?php
$e=there is an error;
try{
throw new Exception ($e);//the throw can exist outside the try
//block (or simply, almost anywhere)
}
try{
$err=34/0;//the compiler should ignore this error
//it is legal because it is in a try block
}
$error=34/0;//the compiler should act on this error
? //this error is illegal
however zend engine will flag the error in the second try block
(an abnormal behavior) instead of ignoring it.
note: when flagging other posters comments as bogus, give logical
reasons for doing so.
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/41012
--
Edit this bug report at http://bugs.php.net/?id=41012edit=1
#41012 [Bgs-Opn]: exception handling
ID: 41012
User updated by: perching_eagle at yahoo dot com
Reported By: perching_eagle at yahoo dot com
-Status: Bogus
+Status: Open
Bug Type: *Compile Issues
Operating System: windows xp
PHP Version: 5.2.1
New Comment:
well the logic behind exceptions is to help you handle ALL types of
errors and i will show you a similar example in python.
python code:
num=input('enter a number, do not enter zero:)
try:
print 34/int(num)
except ZeroDivisionError:
print error,you entered zero
(if you enter 2) output: 17
(if you enter 0) output: error, you entered zero
#java does exactly the same thing.
simple code, i didn't have to explicitly throw any exception (using the
throw keyword) or include an if statement. this obeys the rule of keep
things simple, and the try keyword actually does something, as opposed
to being a mere decoration as it is now in PHP.
Previous Comments:
[2007-04-08 15:11:42] [EMAIL PROTECTED]
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
Fatal errors are not exceptions and therefor try {} does nothing to
catch them.
[2007-04-06 21:00:29] perching_eagle at yahoo dot com
?php
$e=there is an error;
try{
throw new Exception ($e);//the throw can exist outside the try
//block (or simply, almost anywhere)
}
try{
$err=34/0;//the compiler should ignore this error
//it is legal because it is in a try block
}
$error=34/0;//the compiler should act on this error
? //this error is illegal
however zend engine will flag the error in the second try block
(an abnormal behavior) instead of ignoring it.
note: when flagging other posters comments as bogus, give logical
reasons for doing so.
[2007-04-06 20:27:20] perching_eagle at yahoo dot com
why is not a bug?
this is an abnormal behavior, that restricts how you use the exception
class. if the try block can't force an erroreneous code to compile,
why do you have the try keyword anyway? the throw keyword could be
used outside a try block and also in a catch block or anywhere else
in the program. in a nutshell, the try keyword has no function at all
in php, if it does, what is it?
the documentation at php.net does not explain the function of the try
keyword in php.
[2007-04-06 18:55:16] [EMAIL PROTECTED]
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
.
[2007-04-06 18:43:25] perching_eagle at yahoo dot com
Description:
the compiler ought to bypass exceptions in try blocks, and allow a
catch block to catch the exception at runtime. in other words, try
blocks should turn compile-time errors to run-time errors. try blocks
shouldn't depend on the throw keyword before throwing exceptions, errors
in try blocks should automatically cause exceptions to be thrown.
otherwise the current Exception class is only as good as this statement
if(class_exists(Book)){//main code} else{//warning code} for the code
in my example.
Reproduce code:
---
?php
try{
$err=new Book(); //class Book does not exist
//more code
}
catch(Exception $e){
print class does not exist;
exit();
// or throw another exception that ends the program
//in another block.
}
Expected result:
output:(should look like this)
class does not exist
(python and java behave like this, i hope there will be some
consistence in logic, among open source languages )
Actual result:
--
program does not compile,
error message: Fatal error (actually says Fatel error),
class 'Book' not found on C://XXX
--
Edit this bug report at http://bugs.php.net/?id=41012edit=1
#41012 [Opn]: exception handling
ID: 41012
User updated by: perching_eagle at yahoo dot com
Reported By: perching_eagle at yahoo dot com
Status: Open
Bug Type: *Compile Issues
Operating System: windows xp
PHP Version: 5.2.1
New Comment:
correction=
for the first line of the python code in the post before this one.
# add qoutes to the parameter in the function 'input()'
num=input(enter a number, do not enter zero:)
the c programming language and other procedural languages can catch
errors just like object oriented laguages that use exceptions, if the
try keyword cannot force the compiler to overlook errors, then you
have to use an if statement, just like in c and actually write more
code. but if the try can suppress errors, you don't have to include
if statements and the throw keyword, you just write catch
statements that can catch each exception and error at runtime, and then
you can continue you code without stopping it or allow the program to
stop after sending a customized message on your site, rather than have
your site or program crash. you just explicitly throw an exception that
closes the program, after sending a customized message for fatal errors
simple.
**
to [EMAIL PROTECTED], a zero division error is an exception, it is not a
fatal error, fatal errors require that you reset the program.they are
errors that should not be caught such as linkage errors and thread death
errors and some machine errors. the program should be allowed to end
gracefully but could still catch them if you wish.
Previous Comments:
[2007-04-10 02:19:36] perching_eagle at yahoo dot com
well the logic behind exceptions is to help you handle ALL types of
errors and i will show you a similar example in python.
python code:
num=input('enter a number, do not enter zero:)
try:
print 34/int(num)
except ZeroDivisionError:
print error,you entered zero
(if you enter 2) output: 17
(if you enter 0) output: error, you entered zero
#java does exactly the same thing.
simple code, i didn't have to explicitly throw any exception (using the
throw keyword) or include an if statement. this obeys the rule of keep
things simple, and the try keyword actually does something, as opposed
to being a mere decoration as it is now in PHP.
[2007-04-08 15:11:42] [EMAIL PROTECTED]
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
Fatal errors are not exceptions and therefor try {} does nothing to
catch them.
[2007-04-06 21:00:29] perching_eagle at yahoo dot com
?php
$e=there is an error;
try{
throw new Exception ($e);//the throw can exist outside the try
//block (or simply, almost anywhere)
}
try{
$err=34/0;//the compiler should ignore this error
//it is legal because it is in a try block
}
$error=34/0;//the compiler should act on this error
? //this error is illegal
however zend engine will flag the error in the second try block
(an abnormal behavior) instead of ignoring it.
note: when flagging other posters comments as bogus, give logical
reasons for doing so.
[2007-04-06 20:27:20] perching_eagle at yahoo dot com
why is not a bug?
this is an abnormal behavior, that restricts how you use the exception
class. if the try block can't force an erroreneous code to compile,
why do you have the try keyword anyway? the throw keyword could be
used outside a try block and also in a catch block or anywhere else
in the program. in a nutshell, the try keyword has no function at all
in php, if it does, what is it?
the documentation at php.net does not explain the function of the try
keyword in php.
[2007-04-06 18:55:16] [EMAIL PROTECTED]
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
.
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/41012
--
Edit this bug report at http://bugs.php.net/?id=41012edit=1
#41012 [NEW]: exception handling
From: perching_eagle at yahoo dot com
Operating system: windows xp
PHP version: 5.2.1
PHP Bug Type: *Compile Issues
Bug description: exception handling
Description:
the compiler ought to bypass exceptions in try blocks, and allow a
catch block to catch the exception at runtime. in other words, try
blocks should turn compile-time errors to run-time errors. try blocks
shouldn't depend on the throw keyword before throwing exceptions, errors in
try blocks should automatically cause exceptions to be thrown. otherwise
the current Exception class is only as good as this statement
if(class_exists(Book)){//main code} else{//warning code} for the code in
my example.
Reproduce code:
---
?php
try{
$err=new Book(); //class Book does not exist
//more code
}
catch(Exception $e){
print class does not exist;
exit();
// or throw another exception that ends the program
//in another block.
}
Expected result:
output:(should look like this)
class does not exist
(python and java behave like this, i hope there will be some
consistence in logic, among open source languages )
Actual result:
--
program does not compile,
error message: Fatal error (actually says Fatel error),
class 'Book' not found on C://XXX
--
Edit bug report at http://bugs.php.net/?id=41012edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=41012r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=41012r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=41012r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41012r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=41012r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=41012r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41012r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41012r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=41012r=support
Expected behavior:http://bugs.php.net/fix.php?id=41012r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=41012r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=41012r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41012r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41012r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41012r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41012r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=41012r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=41012r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=41012r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41012r=mysqlcfg
#41012 [Opn]: exception handling
ID: 41012
User updated by: perching_eagle at yahoo dot com
Reported By: perching_eagle at yahoo dot com
Status: Open
Bug Type: *Compile Issues
Operating System: windows xp
PHP Version: 5.2.1
New Comment:
?php
$e=there is an error;
try{
throw new Exception ($e);//the throw can exist outside the try
//block (or simply, almost anywhere)
}
try{
$err=34/0;//the compiler should ignore this error
//it is legal because it is in a try block
}
$error=34/0;//the compiler should act on this error
? //this error is illegal
however zend engine will flag the error in the second try block
(an abnormal behavior) instead of ignoring it.
note: when flagging other posters comments as bogus, give logical
reasons for doing so.
Previous Comments:
[2007-04-06 20:27:20] perching_eagle at yahoo dot com
why is not a bug?
this is an abnormal behavior, that restricts how you use the exception
class. if the try block can't force an erroreneous code to compile,
why do you have the try keyword anyway? the throw keyword could be
used outside a try block and also in a catch block or anywhere else
in the program. in a nutshell, the try keyword has no function at all
in php, if it does, what is it?
the documentation at php.net does not explain the function of the try
keyword in php.
[2007-04-06 18:55:16] [EMAIL PROTECTED]
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
.
[2007-04-06 18:43:25] perching_eagle at yahoo dot com
Description:
the compiler ought to bypass exceptions in try blocks, and allow a
catch block to catch the exception at runtime. in other words, try
blocks should turn compile-time errors to run-time errors. try blocks
shouldn't depend on the throw keyword before throwing exceptions, errors
in try blocks should automatically cause exceptions to be thrown.
otherwise the current Exception class is only as good as this statement
if(class_exists(Book)){//main code} else{//warning code} for the code
in my example.
Reproduce code:
---
?php
try{
$err=new Book(); //class Book does not exist
//more code
}
catch(Exception $e){
print class does not exist;
exit();
// or throw another exception that ends the program
//in another block.
}
Expected result:
output:(should look like this)
class does not exist
(python and java behave like this, i hope there will be some
consistence in logic, among open source languages )
Actual result:
--
program does not compile,
error message: Fatal error (actually says Fatel error),
class 'Book' not found on C://XXX
--
Edit this bug report at http://bugs.php.net/?id=41012edit=1
#41012 [Bgs-Opn]: exception handling
ID: 41012
User updated by: perching_eagle at yahoo dot com
Reported By: perching_eagle at yahoo dot com
-Status: Bogus
+Status: Open
Bug Type: *Compile Issues
Operating System: windows xp
PHP Version: 5.2.1
New Comment:
why is not a bug?
this is an abnormal behavior, that restricts how you use the exception
class. if the try block can't force an erroreneous code to compile,
why do you have the try keyword anyway? the throw keyword could be
used outside a try block and also in a catch block or anywhere else
in the program. in a nutshell, the try keyword has no function at all
in php, if it does, what is it?
the documentation at php.net does not explain the function of the try
keyword in php.
Previous Comments:
[2007-04-06 18:55:16] [EMAIL PROTECTED]
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
.
[2007-04-06 18:43:25] perching_eagle at yahoo dot com
Description:
the compiler ought to bypass exceptions in try blocks, and allow a
catch block to catch the exception at runtime. in other words, try
blocks should turn compile-time errors to run-time errors. try blocks
shouldn't depend on the throw keyword before throwing exceptions, errors
in try blocks should automatically cause exceptions to be thrown.
otherwise the current Exception class is only as good as this statement
if(class_exists(Book)){//main code} else{//warning code} for the code
in my example.
Reproduce code:
---
?php
try{
$err=new Book(); //class Book does not exist
//more code
}
catch(Exception $e){
print class does not exist;
exit();
// or throw another exception that ends the program
//in another block.
}
Expected result:
output:(should look like this)
class does not exist
(python and java behave like this, i hope there will be some
consistence in logic, among open source languages )
Actual result:
--
program does not compile,
error message: Fatal error (actually says Fatel error),
class 'Book' not found on C://XXX
--
Edit this bug report at http://bugs.php.net/?id=41012edit=1
