Jump to content

syntax error detection


Go to solution Solved by kicken,

Recommended Posts

It seems like lately my scripts don't show up the simple little syntax errors like they used to do. Probably because my host upgraded the php version (now at 5.6.35).

 

This line (with errors set at E_ALL & E_NOTICE btw):

$start_time = str_replace($sch_items, $repl_items, $row['start_time'];

does not show up as an error any longer. This kind of thing has been going on for several months and I just discovered this specific issue as a culprit. Many times I write some new code and naturally make a few typos and then have to SEARCH LONG AND HARD to find the little errors that I have made.

 

For those still reading, the problem above is the missing ) at the end of the statement. Why don't I get an error message?

Edited by ginerjm
Link to post
Share on other sites

Use phpinfo() and check "Loaded Configuration File" setting to make sure you are actually using the ini file that you think you are. The error settings will be found in the "Core" section of the output.

Link to post
Share on other sites

If the setting is literally "E_ALL & E_NOTICE" then that only enables notices. It should be "E_ALL | E_NOTICE"... except E_ALL includes E_NOTICE so really just "E_ALL" is fine.

Link to post
Share on other sites

My typography mis-directed you - the settings include both options and probably don't need to.

 

As for php.ini - I add an error settings module that includes my desired settings into every script I write. There is also an switch check in that module to allow my scripts to turn on full error checking or not which I use when necessary. In the cases that concern this question that switch is turned on for development and the values is 32767 (I checked)

Link to post
Share on other sites

Setting the error reporting values in your script is less than ideal. If, for example, your script had a parse error then PHP would bail before ever setting your error settings as the script is never executed. If your application works like many frameworks these days and has a small front-end script that sets the error configuration then include's other files you're probably fine though as the setting would be applied prior to the include being executed.

 

For your live server, setup your php.ini file with an error_log value pointing to a file somewhere you can check for errors and display_errors=off.

 

For your development server you can set display_errors=on and error_reporting=E_ALL to hopefully get the errors in the browser directly. If you're using a fast-cgi setup for PHP you might need to configure it to pass through the errors as well.

Link to post
Share on other sites

For development I have always used my little err setting module and for all except fatal errors that crash the script I usually got a message that got me thru all my typos and such. Nowadays I am not. So did some recent version change alter this behavior?

 

Like right now - I made a few changes to a script and introduced an error and my script won't run and I'm not getting the usual messages that I always got before.

 

I understand what Kicken says about doing my error control this way but it has worked for years and I've been happy.

Link to post
Share on other sites

if you were seeing fatal parse errors before, it was because of the configuration settings, not anything you were doing in the code (unless the errors were in a required/included file and the settings were either in the main file or a file included/required before the one where the error is at.) if you are not seeing them now, it's because the configuration settings are different.

 

use a .php script with a phpinfo() statement in it to find what the master/local error_reporting, display_errors, and log_errors settings are.

Link to post
Share on other sites

It appears that something has changed in that case. I used to see almost every simple error and rarely had "fatal ones" that stopped the script. Now everything seems to be going to the error_log file.

 

display errors - set to off

error reporting - 32767

error_log - error_log

log_errors - on

 

Anything else I should look at?

Link to post
Share on other sites
  • Solution

Your host probably re-configured things when it upgrade PHP. In the past many shared hosting providers I used would have things configured with display_errors=On but that's not an ideal configuration for a production server as it exposes too much. Your host was probably setup like that previously and when they upgraded finally changed it to the better display_errors=Off with logging setup instead.

 

The old configuration would let you see the parse errors because of the PHP configuration, not your script specific settings. The new configuration doesn't show the errors, and your script can't override that if it can't be parsed.

 

So your options now are

  • Re-configure PHP to show errors again or
  • Start checking the error log file when you get a blank screen or
  • Re-work your application to use a main front-end file that sets your error reporting then require's the rest of your code.
Link to post
Share on other sites
This thread is more than a year old.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.