Error reporting after upgrade

[sirugo]

After upgrading PHP I'm not feeling comfortable about how the error reporting works.

With the previous version I got reports caused by errors like:

if($a > 1)
{

}

(empty curly braces)

or forgotten curly braces at the ebd of the script

These don't show up anymore which leads to a never ending search for curly braces...
How can I get them back?

 

[sirugo]

..or forgotten semicolons.
I only get a blank page.
The error_reporting level is set to 2047 (or even tried 4096) but still nothing.

 

[jpadie]

i am surprised you got errors from empty curly braces. I never have! I guess you have been using E_STRICT.

strangely the error levels are not cumulative. the E_STRICT level will provide feedback that E_ALL does not.

 

[sirugo]

I tried to change to E_STRICT. I "forgot" the last curly brace in the script and I get a blank page. With the previous PHP-version (can't remember exactly which) I got a weird message saying that "unexpected $" or something like that. It always reminded me to close the braces.
Also a forgotten ";" now gives me a blank page which is pretty annoying, considering that it's quite hard to find those when you write a lot of code before testing the script. Is there no way to get it back?

Running PHP 4.4.4

 

[sirugo]

Actually I'm running the Apache server and the server is also new with a new .htaccess file. I found this URL. Maybe I need to change the .htaccess file?

http://forum.dreamhosters.com/programming/45191-php-hiding-full-paths-in-error-messages.htm

 

[jpadie]

do you have display_errors set to ON in your php.ini file?

i would not look at htaccess etc until ensuring that php.ini is properly set up (occam's razor etc)

 

[sirugo]

It's not set in php.ini but I'm setting it in runtime during the developing process:

ini_set('display_errors', 1);
ini_set('error_reporting', 2048);
ini_set('mysql.trace_mode', 1);

After setting the values I've checked that they get properly set and they do.
Error reporting works but not the way it worked before, not showing the warnings/errors described above...

 

[jpadie]

setting in runtime will not work if there is a parse error as the code never actually gets run. change the php.ini file and restart the webserver.

set display_startup_errors to on too.

you might be able to do this all in run time provided you then "include" your actually code from a separate file

e.g.

ini_set('display_errors', 'On');
error_reporting(E_STRICT);
include "somephpfile.php';

 

[sirugo]

OK, I was doing the reverse: I have a file to which I'm including the reporting commands. Isn't that the same?

 

[jpadie]

not the same, no. php (i do not thing) parses the included files at runtime for parse errors. it only parses them when the interpreter gets to that line in the code.

but it is much much better to change your php.ini file. then you remove all the complicating factors.

 

[sirugo]

OK, but there's a security issue with displaying errors.
If I change it in the php.ini to display errors, can I hide the error messages at runtime?

 

[jpadie]

there is a security issue, yes. but if you want to debug your application you either need to display the errors or read your logs.

once you have debugged your application, turn display_erros back off.

 

[jpadie]

i should add, of course, that you can set display_errors to OFF at runtime providing there are no parse errors in your application.

ini_set('display_errors", 0);

 

[sirugo]

I can't turn the on and off in the php.ini all the time.
I'mdeveloping five apps at the same time and all of the old ones constantly need to be changed or updated. There must be a way to get those warnings back without having to tamper with the php.ini all the time.
I'll try to turn them on then turn them off at runtime.

 

[jpadie]

These are not warnings you are talking about: you have parse errors. You should not be developing an application that still has parse errors on a live box (if you are). when you are developing you keep display_errors turned on to assist. you then deploy to a production box that is properly locked down.

If you have only one physical box and you are running apache then you can still have php behaving differently for different applications simply by using an .htaccess or httpd.conf file in the relevant directoy. see

http://us2.php.net/manual/en/configuration.changes.php

if you are running php as a cgi then you need only upload a different php.ini file to the relevant directory.