2

In PHP 5.5.9 ini_set('display_errors', 1) can fail, as in:

<?php
ini_set('display_errors', 1);
error_reporting(E_ALL);     
//nosuchfunction();// Display Errors succeeds. "Fatal error: Call to undefined function"
$test=array(1 2 ); // Display Errors fails! No error displayed. HTTP ERROR 500
?>

How can I fix this?

ChrisJJ
  • 2,191
  • 1
  • 25
  • 38
  • 2
    working at my end:- Parse error: syntax error, unexpected '2' (T_LNUMBER), expecting ')' in D:\xampp\htdocs\abc.php on line 5 – Alive to die - Anant Sep 28 '16 at 14:43
  • read the ist line, this is not version problem: `http://php.net/manual/en/function.ini-set.php` – devpro Sep 28 '16 at 14:44
  • 1
    Your question's unclear; what's it really about? Hasn't Ed's answer not solve this for you? If not, then you will need to elaborate on your question. *"How may I fix this?"* - Fix what exactly? – Funk Forty Niner Sep 28 '16 at 15:27
  • @Anant, thanks. That's exactly the kind of error display I would expect. Any idea why you get it but I (on PHP 5.5.9 CGI) don't? – ChrisJJ Sep 28 '16 at 20:37
  • "This question has been asked before and already has an answer." Sure not at the question you cite. That does not ask about ini_set('display_errors'). – ChrisJJ Sep 29 '16 at 22:58
  • 1
    @ChrisJJ Yes, it does. It's literally right there in the question. You seem to be missing what multiple people have tried to explain to you - PHP just doesn't work the way you think it should. – elixenide Sep 29 '16 at 23:04
  • 1
    It works for @Anant above because error reporting is configured in their php.ini to show errors by default. The `ini_set` is doesn't work any more in their case than in yours, just their defaults differ. – deceze Sep 30 '16 at 08:24
  • "It works for @Anant above because error reporting is configured in their php.ini to show errors by default. " Where did Anant say his/her php.ini is configured so? – ChrisJJ Sep 30 '16 at 11:26
  • 1
    It's the only possible explanation for the behaviour. – deceze Sep 30 '16 at 13:25

1 Answers1

13

tl;dr Your first sample error—a call to an undefined function—is one you can display by using ini_set() in the same script. The second error—a syntax error in array(1 2 )—cannot be displayed using ini_set() in the same script because PHP never even starts to execute the broken script. To view that error, you have to do one of three things: (1) change the config file, (2) call ini_set() in another script and include the broken script, or (3) just look at the server logs instead of displaying the error on-screen.

The Problem with the Script

Your problem isn't with ini_set(); it's a syntax error with this line:

$test=array(1 2 );

As you know, that is invalid PHP because you just have 2 adjacent numbers, with no comma separator. From the manual (emphasis added):

An array can be created using the array() language construct. It takes any number of comma-separated key => value pairs as arguments.

You probably meant:

$test=array(1, 2 );
//           ^ Notice the comma. This is important!

Why You See No Output

The syntax error causes a parser error, a/k/a the "white screen of death." The parser gives up and dies at the parsing stage. That means it never runs a single line of the script, including your ini_set() or error_reporting() calls. So, you don't get any output, though the error would still show up in your server logs.

The critical point: The PHP engine never runs any part of a script with a syntax error. This means ini_set() and error_reporting() calls don't run, either. You have to set the configuration option before PHP chokes on the broken script. You can do that in php.ini or in another file. You cannot do it in the same file that contains the syntax error.

How to Force On-Screen Output of the Error

Based on the comments, it sounds like you are trying to cause a parser error and then display it on the screen. You can't do this with ini_set() in the same script because PHP fails at the parsing stage. That is, it can't even interpret the script safely, so it stops trying, and no lines of code in that script are ever executed.

To work around this, you need to do one of two things, as explained in this canonical answer:

  1. Add these lines to your php.ini file:

    error_reporting = E_ALL
display_errors = 1

    or

  2. wrap the broken script in an include or require, like this:

    <?php
error_reporting(E_ALL);
ini_set("display_errors", 1);
include("./broken-script.php");

Nota bene: Never do this in production. If you want to do it in development or QA, fine, but displaying raw PHP errors on-screen in production is a security risk.

Community
  • 1
  • 1
elixenide
  • 44,308
  • 16
  • 74
  • 100
  • 1
    True. However `$test=array('1 2' );` could (also) have been valid ;-) – Funk Forty Niner Sep 28 '16 at 14:52
  • 1
    @Fred-ii- True. I'm admittedly guessing here. OP may also have meant `$test=array(12);` In any case, that line is the culprit. – elixenide Sep 28 '16 at 14:53
  • *Aye*, true (right) again Ed. That space between the integers is creating a "hole" (if I can say) and it being considered as a "string" is the culprit. – Funk Forty Niner Sep 28 '16 at 14:55
  • To add: you're right about the missing comma, since they're using `array()`. It wouldn't make any sense to use `array(12)`, unless they'd want to explode on them and to separate them later. Kind of hard to get into the OP's head here as to what the question's really about, wouldn't you agree? – Funk Forty Niner Sep 28 '16 at 15:02
  • If you look at the comments in the code OP provided, there's a call to a deliberate undefined function, which gives an error-message. Then he tries to get his error-message to display with the broken `array(1 2);`, so perhaps the question is why one displays the error, while the other doesn't? Although, quite unclear when there is very little text along with the code... – Qirel Sep 28 '16 at 15:07
  • @Qirel The call to an undefined function is a normal, fatal error, which kills the script but can still be displayed. The `array(1 2)` is a syntax error, which leads to a white screen of death. The parser just gives up and dies, writing the error to the log instead of the screen. Why doesn't it also display it on screen? That's just the way it is (though there are some good arguments both ways). – elixenide Sep 28 '16 at 15:18
  • 1
    @Ed Yup, I'm not disagreeing with you - I'm just trying to understand what the question really was about ;-) – Qirel Sep 28 '16 at 15:24
  • @Qirel [*As were I...*](http://stackoverflow.com/questions/39750712/how-do-i-get-ini-setdisplay-errors-1-to-work-properly/39750872?noredirect=1#comment66798499_39750872) ;-) – Funk Forty Niner Sep 28 '16 at 15:27
  • @Ed "Your problem isn't with ini_set(); it's a syntax error with this line" There's no problem with that line. That line is precisely as intended as something that should cause a displayed error. The problem is that -- despite the ini_set -- there is no displayed error. – ChrisJJ Sep 28 '16 at 20:33
  • 1
    @ChrisJJ there is a problem with that line - a syntax error - and the entire point of my post is that such errors result in the "white screen of death." You aren't going to be able to display it on-screen using `ini_set()`. If you look at the linked post, however, you will see that you *can* turn on display of those errors by editing your `php.ini` file. You just can't do it dynamically at runtime. – elixenide Sep 28 '16 at 20:39
  • @ChrisJJ I updated my answer to provide more guidance. Please accept it if you found it helpful. – elixenide Sep 28 '16 at 20:50
  • @Ed "there is a problem with that line - a syntax error" You're mistaken. The syntax error is not a problem. It is there to demonstrate the problem, which is failure of the error to display. Thanks for your workarounds -- I''ll consider those if I don't get the info from Anant on how s/he avoids the fail without workarounds. – ChrisJJ Sep 29 '16 at 14:08
  • 1
    @ChrisJJ I'm afraid you're missing the point. The syntax error *is* a problem because syntax errors are *not* like other errors. Put differently, an undefined function and a syntax error are in different categories. You cannot display a parser error with `ini_set()` in the same script. That's the entire point of your question: you tried, and it doesn't work. You must use one of the workarounds that I described: change the config file, call `ini_set()` in a file that `include`s the broken file, or look at your server logs (not the screen) for the error. There simply is no other way to do this. – elixenide Sep 29 '16 at 14:20
  • 1
    @ChrisJJ I've tried to add some clarity to my answer. This is the part you really need to read: ***The critical point:*** The PHP engine never runs any part of a script with a syntax error. This means `ini_set()` and `error_reporting()` calls don't run, either. You have to set the configuration option *before* PHP chokes on the broken script. You can do that in `php.ini` or in another file. You *cannot* do it in the same file that contains the syntax error. – elixenide Sep 29 '16 at 14:27
  • 2
    @ChrisJJ You may have the wrong expectation of how PHP works. It doesn't read and immediately execute the file line by line. There's a parsing step in which the entire file gets parsed, followed by the runtime in which the code is executed. A syntax error fails within the first step, after which there isn't a second step. – deceze Sep 29 '16 at 14:33
  • "You may have the wrong expectation of how PHP works." An expectation that display_errors does what it says. An expectation met by the test of at least one other user here. – ChrisJJ Sep 29 '16 at 23:00
  • 1
    @ChrisJJ As deceze pointed out, the only way Anant could get the output in [that comment](http://stackoverflow.com/questions/39750712/how-do-i-get-ini-setdisplay-errors-to-work-properly#comment66797637_39750712) is to have the setting in `php.ini`. It really is that simple: what you want to do is impossible, which is why it didn't work for you and what prompted you to post the question in the first place. If you want to force on-screen output of syntax errors, modify your `php.ini`. – elixenide Sep 30 '16 at 17:11