If the bug #48583 can't be accepted through bugs.php.net, I think it makes
sense to discuss it here.
In short the question is:
Should display_errors and the other error-routing settings work or not?
I belive they are very important and should always work.
Just my 2cents.
Long story:
display_errors=off setting won't stop some errors from appearing in the
output.
Any errors thrown by modules at the initialization phase shoud be
accumulated somewhere, not passed to the output directly.
In partcilar, if you have an error in php.ini, display_errors=OFF won't
have any effect.
Reproduce code:
php.ini:
error_reporting=E_ALL | E_DEPRECATED
error_log="D:\php-5.3RC3-Win32\php.log"
log_errors=On
display_errors=Off
#something
;a comment
command line:
php-cgi.exe -i >somefile.html
Expected result:
nothing in the output
Actual result:
2 errors appeared on screen:
PHP Deprecated: Comments starting with '#' are deprecated in
D:\php-5.3RC3-Win32\php.ini on line 5
in Unknown on line 0
PHP Warning: Unknown: It is not safe to rely on the system's timezone
settings. You are required
to use the date.timezone setting or the date_default_timezone_set()
function. In case you used any o
f those methods and you are still getting this warning, you most likely
misspelled the timezone iden
tifier. We selected 'Europe/Moscow' for '4.0/DST' instead in Unknown on
line 0
jvlad kirjoitti:
If the bug #48583 can't be accepted through bugs.php.net, I think it makes
sense to discuss it here.
It's not a bug but "chicken'n'egg'" issue. Errors are displayed by default
(IIRC) so if the ini file does not get parsed an error is outputted which IS
really good thing. Just fix that damn ini file. :)
--Jani
If the bug #48583 can't be accepted through bugs.php.net, I think it
makes
sense to discuss it here.It's not a bug but "chicken'n'egg'" issue. Errors are displayed by default
(IIRC) so if the ini file does not get parsed an error is outputted which
IS
--Jani
I don't agree, absolutely.
Settings are more important and should be parsed/loaded first.
If any error happens before this phase is complete, they should be captured
and buffered for later processing, unless the error is fatal.
After the settings are loaded, all buffered errors should be processed and
handled according to the settings. Nothing else.
Do you see any problems with this approach? Where is the promissed
chicken&egg issue? :)
really good thing. Just fix that damn ini file. :)
Sorry, but seems you do not understand the situation.
How would an admin fix that damn ini file if the errors are not appearing in
the log?????
Say, I'm a hosting company admin. I install packages, php in particular,
make changes to configs, etc. I do not know what web sites are running and
do not want to see if anything related to my work appear in their pages.
Never. What steps am I supposed to do to see that php.ini contains bogus #?
Take in to account that some of the errors do not appear in the output at
all. They are crashing php because passed to the handler too early.
If the bug #48583 can't be accepted through bugs.php.net, I think it
makes
sense to discuss it here.
It's not a bug but "chicken'n'egg'" issue. Errors are displayed by
default
(IIRC) so if the ini file does not get parsed an error is outputted
which
IS
--Jani
I don't agree, absolutely.
Settings are more important and should be parsed/loaded first.
If any error happens before this phase is complete, they should be
captured
and buffered for later processing, unless the error is fatal.
After the settings are loaded, all buffered errors should be
processed and
handled according to the settings. Nothing else.Do you see any problems with this approach? Where is the promissed
chicken&egg issue? :)really good thing. Just fix that damn ini file. :)
Sorry, but seems you do not understand the situation.
How would an admin fix that damn ini file if the errors are not
appearing in
the log?????
Say, I'm a hosting company admin. I install packages, php in
particular,
make changes to configs, etc. I do not know what web sites are
running and
do not want to see if anything related to my work appear in their
pages.
Never. What steps am I supposed to do to see that php.ini contains
bogus #?
Take in to account that some of the errors do not appear in the
output at
all. They are crashing php because passed to the handler too early.
I have to say I agree; exposing such errors can be a potential
security risk.
-- Gwynne