PHP 5.3 - Troubleshooting 500 Errors - Debugging - Parse Errors
PHP will respond with a "500" when it encounters a Fatal error, such as E_PARSE
, E_ERROR
and uncaught exceptions. 500 is the HTTP response code for "Internal Server Error" - something unrecoverable happened while processing the request.
In your php.ini, on a development machine, you should set your error_reporting
level to (at least) E_NOTICE
- preferably E_ALL
- and make sure display_errors
is on. This will show you the error message in the browser, including for "500" errors.
You can also check your Apache error logs, the errors will be listed there, as long as log_errors
is enabled in php.ini. By default, this will be at <apache_ServerRoot>\logs\error.log
.
You can also control all this at run time with ini_set()
and error_reporting()
BuddyJoe
I like to code C# and work with the web. Still learning.
Updated on June 14, 2022Comments
-
BuddyJoe almost 2 years
Occasionally I will have some badly formed PHP code and I will get a 500 error. I'm running Apache 2.2 on a Windows 7 laptop. As an IDE I have started using PhpStorm.
What is the best way to catch these errors and be informed of the line number? Why do the OOP-related syntax errors tend to throw 500 errors and function problems tend to return normal errors?
Example of syntax mistake: calling a static method from a class with a single colon instead of two colons.
UPDATE: Please see accepted answer and all comments.
-
BuddyJoe over 12 yearsThat static situation must be an E_PARSE error. It was just so hard to find the issue - I was thinking there has got to be a better way.
-
DaveRandom over 12 years@brunot if you don't see the messages with
error_reporting
on, chances aredisplay_errors
is off. There are situations in which the error message will not be output, but this is only really if something went very wrong with PHP internally and it crashed. When this happens, there is usually a message in the Apache logs that tells you that it happened, although debugging why it happened can be very difficult indeed. In this situation, running the script from the command line sometimes helps get a useful error message, but not always. -
DaveRandom over 12 years@brunot For finding
E_PARSE
errors you can load the script from the command line with the-l
(lint) option and it will give you the error message telling you the line number where the parse error occured. -
BuddyJoe over 12 yearsDug a little deeper (and hoping you can confirm that this sounds right) - but when I set the display_errors = On in the ini directly versus doing it from the top of the script... it caught the issue :). Thanks for the lint method. That will also help a lot!
-
DaveRandom over 12 yearsYep, if it is a parse error, none of your code is executed - so your call to
ini_set()
makes no difference. The only exception to this is if youinclude()
a file that doesn't parse, in which case the code before the call toinclude
would have been executed. This is (AFAIK) only type of run-time error for which this holds true. But in a dev environment, you should always show all errors anyway, so you can catch them and fix them, so setting it in php.ini is the best way :-)