PHP 5.3 - Troubleshooting 500 Errors - Debugging - Parse Errors

11,865

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()

Share:
11,865
BuddyJoe
Author by

BuddyJoe

I like to code C# and work with the web. Still learning.

Updated on June 14, 2022

Comments

  • BuddyJoe
    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
    BuddyJoe over 12 years
    That 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
    DaveRandom over 12 years
    @brunot if you don't see the messages with error_reporting on, chances are display_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
    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
    BuddyJoe over 12 years
    Dug 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
    DaveRandom over 12 years
    Yep, 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 you include() a file that doesn't parse, in which case the code before the call to include 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 :-)