5

I had an old codesetup from some other developer and I am setting up the same on my server, there I saw a line

<?php @$Days = $_POST['Days']; ?>

This code runs well on my local setup but once I uploaded it on server this did not worked and returned a network error and all the code/HTML after this code also did not work.

Although, I debugged this issue and have removed this. Also, I know that to handle the errors we use the @ symbol, and also I have read this question

My query is that what was the error in the above case, why was it not shown, if I want to check the error then what shall I do.

For error reporting I shall tell you that I already used the below code

<?php
ini_set("display_errors", "1");
error_reporting(E_ALL);
?>

So please tell me why was my code unable to get past this statement, as I have around 100's of such code blocks. Is there any setting in php which could help me to get over this.

Community
  • 1
  • 1
Rohit Ailani
  • 910
  • 1
  • 6
  • 19
  • are you sure you read that question? `@` suppresses/ignores errors and you don't handle errors by ignoring them. it's like saying that you handle your credit card debts by ignoring the repayment notices you get – Memor-X Oct 06 '16 at 05:43
  • Yes and I know that @ suprresses the error by certain functions, I am unclear what it does in my case, in front of variable name. – Rohit Ailani Oct 06 '16 at 05:46
  • *"to handle the errors we use the @ symbol"* -- this is plain wrong. By putting `@` in front of a statement you don't handle the errors. You [pretend they didn't happen](http://php.net/manual/en/language.operators.errorcontrol.php). It's a big difference. – axiac Oct 06 '16 at 08:34
  • If you haven't seen the error, how are you sure that that line is causing the fatal error? The only message that @ is suppressing is a Notice (low priority warning) if there is no such value in the $_POST array. Silent or not, that shouldn't stop the script, so the problem might be somewhere else. – IMSoP Oct 06 '16 at 08:40

1 Answers1

4

The @ is the error suppression operator in PHP, have a look at the documentation.

In your example, it is used before the variable name to avoid the E_NOTICE error there. If in the $_POST array, the 'Days' key is not set it will throw an E_NOTICE message, but @ is used there to avoid that E_NOTICE.

The cause of the code not working on the server is probably due to the scream.enabled directive in your php.ini configuration being disabled.

Disabling scream should fix the issue.

Change the directive in your php.ini, like so:

scream.enabled = 0

If you want to disable it during run-time, then you can use ini_set as stated in the manual:

ini_set('scream.enabled', false);

Edit

Someone in the comments pointed out I haven't been thorough enough with my answer. I will try to amend my mistake in this here edit :).

The reason scream (and disabling the @) can / will break the code is due to the fact that the variable doesn't have a value. If the remainder of the code tries to use the variable it will throw an error.

Also, an E_NOTICE can throw an error if you attach an error handler to it. A quote from another question:

The above code will throw an ErrorException any time an E_NOTICE or E_WARNING is raised, effectively terminating script output (if the exception isn't caught). Throwing exceptions on PHP errors is best combined with a parallel exception handling strategy (set_exception_handler) to gracefully terminate in production environments.

Community
  • 1
  • 1
Rick van Lieshout
  • 2,276
  • 2
  • 22
  • 39
  • 2
    A Notice will not stop execution, with our without scream, so I'm not sure this is really going to help. – IMSoP Oct 06 '16 at 08:38
  • True enough, it won't always cause an error but without the actual error message this is the best I could do :) Let me add some info the the answer to improve it, thanks. – Rick van Lieshout Oct 06 '16 at 08:40
  • Thanks for the information @RickvanLieshout, I debugged this further, and actually the variable declaration was not causing the error. It was being used as This was really causing the problem. – Rohit Ailani Oct 06 '16 at 09:01
  • Yeah that was what I expected. 15 mins ago I made an edit thanks to IMSoP which explained this. Glad we could help you out. Remember to accept the answer, + mister IMSop and enjoy your coding! – Rick van Lieshout Oct 06 '16 at 09:05
  • Thanks rick and @IMSoP for figuring the things out. This was a real blunder made by the other developer have replaced the code at most of the places as setting ini_set('scream.enabled', false); did not server the purpose, may be the server does not supports changing things via ini_set. Anyways helpful discovery. – Rohit Ailani Oct 06 '16 at 09:45
  • 1
    I still don't see what scream has to do with anything (an extension which, by the way, I've never heard of before, and isn't part of the default build of PHP). If you silence a notice, exactly the same thing happens as if you ignore it. I find PHP's notices "too noisy" most of the time anyway, so tend to have them switched off. – IMSoP Oct 06 '16 at 10:21