PHP5.4
php.ini:
log_errors = On
error_log = /tmp/log.txt
error_reporting=E_ALL
and now that code as:
<?php
#asdfasdfxxxasdfas();
?>
the error can't logged in /tmp/log.txt
Because you are used Error Control Operators, from PHP Manual:
Currently the "#" error-control operator prefix will even disable
error reporting for critical errors that will terminate script
execution. Among other things, this means that if you use "#" to
suppress errors from a certain function and either it isn't available
or has been mistyped, the script will die right there with no
indication as to why.
Related
I tried enabling error display using php.ini file, but that didn't work.
Then tried adding error_reporting(E_ALL), didn't work, after that I tried ini_set("display_errors", "on"), this option worked for me. My question is how these methods work and when to use which option?
ini_set()
A simple function to set a php.ini configuration at run-time, for that local script.
PHP's docs say
Sets the value of the given configuration option. The configuration option will keep this new value during the script's execution, and will be restored at the script's ending.
So basically if your PHP config doesn't have error_reporting enabled, you can simply enable it at the top of your script:
ini_set('display_errors', '1');
But ini_set() is not exclusive for PHP errors, you can set whatever configuration supported by PHP.
ini_set('SMTP', 'smtp.gmail.com');
ini_set('smtp_port', 25);
error_reporting()
As per PHP Manual
error_reporting — Sets which PHP errors are reported
The error_reporting function sets the level of visibility of errors to the end-user.
These are some the reporting options you get and what they stand for, most are pretty straight-forward:
0
Turns off all PHP errors display
E_ALL
shows all errors
E_ERROR
Fatal run-time errors. These indicate errors that can not be recovered from, such as a memory allocation problem. Execution of the script is halted.
E_WARNING
Run-time warnings (non-fatal errors). Execution of the script is not halted.
E_PARSE
Compile-time parse errors. Parse errors should only be generated by the parser.
E_NOTICE
Run-time notices. Indicate that the script encountered something that could indicate an error, but could also happen in the normal course of running a script.
A little side note I find interesting, remember those key words are constants and they hold integers (numbers), not strings. For example:
echo E_ALL; // 32767
echo E_ERROR; // 1
echo E_WARNING; // 2
echo E_PARSE; // 4
echo E_NOTICE; // 8
You can view all of PHP's predefined constants here.
I am repairing some old code that was made before me and I took about 2 hours to find a error because it was hidden by #.
Is that a way to deactivate this in PHP?
display_errors don't get errors hidden by #
You can define a custom error handler as described in the php documentation for error control operator
You can enable track_errors to save whatever error was generated by the error control operator (#) to a PHP variable. You can set track_errors in your php.ini file or use ini_set.
If the track_errors feature is enabled, any error message generated by
the expression will be saved in the variable $php_errormsg. This
variable will be overwritten on each error, so check early if you want
to use it.
Example
<?php
ini_set('track_errors', true);
#strpos();
echo $php_errormsg;
Will output:
strpos() expects at least 2 parameters, 0 given
Caveats
It is important to note that critical errors that cause the script to terminate that are suppressed by # will not be discoverable this way. In this case, if your script dies unexpectedly and without an error message, that should be a good indication to search for the # in your code.
Currently the "#" error-control operator prefix will even disable
error reporting for critical errors that will terminate script
execution. Among other things, this means that if you use "#" to
suppress errors from a certain function and either it isn't available
or has been mistyped, the script will die right there with no
indication as to why.
For some reason on this particular script, which is a copy of a script I use in a lot of other places, I am not getting any PHP errors. It simply shows a blank page, and It took me a long long time to hunt down a missing semi-colon this morning. Why arn't errors showing up?
my PHP.INI for this sub-domain:
display_errors = On
short_open_tag = On
memory_limit = 32M
date.timezone = Europe/Paris
The code at the top of the page:
session_start();
error_reporting(E_ALL);
ini_set('display_errors', '1');
The Sub Domain is set to run PHP as an Apache Module Which is the same as every other domain I use.
So I am not sure why I am not getting errors displayed. Can anyone tell me?
EDIT:
This is solved, because the errors I was producing were on the page where I had got the lines:
error_reporting(E_ALL);
ini_set('display_errors', '1');
written. When I put the error on to a seperate page and included it, I could see the error fine.
I guess that's why they use bootstrapping!
You should set error_reporting to E_ALL in the php.ini as well: when a parse error occurs (such as a missing semicolon), your error_reporting(E_ALL) won't be used.
You could try to change this lines to get more information from php:
; The display of errors which occur during PHP's startup sequence are handled
; separately from display_errors. PHP's default behavior is to suppress those
; errors from clients. Turning the display of startup errors on can be useful in
; debugging configuration problems. But, it's strongly recommended that you
; leave this setting off on production servers.
display_startup_errors = On
; When PHP displays or logs an error, it has the capability of formatting the
; error message as HTML for easier reading. This directive controls whether
; the error message is formatted as HTML or not.
; Note: This directive is hardcoded to Off for the CLI SAPI
html_errors = On
error_reporting(E_ALL);
ini_set('display_errors',1);
ini_set('display_startup_errors',1);
I have recently taken over development of a legacy system and want to be able to turn on logging of PHP E_NOTICE's on the deployment environment. The deployment environment ini has the following directives...
error_reporting = E_ALL & ~E_DEPRECATED
display_errors = Off
log_errors = On
I have compared the error_reporting bitmask by using echo (E_ALL & ~E_DEPRECATED).' = '.error_reporting();, and both match, so I know the error_reporting level isn't changed within the system itself, and if I turn display_errors = On notices are displayed, but not logged.
So how can I start logging PHP E_NOTICE's?
Update:
According to #m.p.c in the comments on this answer, errors are being displayed in the browser when display_errors is on, but they aren't appearing in the log. I was assuming errors weren't appearing at all.
Are E_NOTICE errors the only ones that aren't appearing in the log, or are all error types affected? If it's all error types, then the first thing I would check is whether or not error logging is even enabled. Try setting ini_set('log_errors', 'On'); at the top of your script. If that doesn't work, then try setting your log file to something you're sure your server can write to by calling ini_set('error_log', 'your_file_path');. If neither of these work, then I think something is seriously wrong with your PHP install. If either of these fixes work, you can put them into your actual php.ini if you have access.
Original Answer:
Based on the error_reporting level in your question, your PHP install should already be setup to report E_NOTICE errors. If it's not logging these errors, something is wrong. I would suggest turning on display_errors to see if any E_NOTICE errors are displayed. If you can't change the php.ini file, try running ini_set('display_errors', 'On'); at the top of your script. Obviously, these errors will only show up and/or be logged if you trigger one, so you should double check that you're actually doing that somewhere.
One caveat is that the E_DEPRECATED error level was only introduced with PHP 5.3. When I just tested setting E_DEPRECATED on a PHP 5.2 install, PHP responded with errors, and set the error_reporting level to 0, which means it reports no errors at all. While it makes no sense for a pre-5.3 php.ini file to use this setting, I feel it's important to at least raise the possibility that you're using E_DEPRECATED on a server that doesn't support it. If you're not sure of your version, you can run phpinfo() and it will display a page with lots and lots of information, including the version number for your install.
Notwithstanding the above, if I've misunderstood your question and you're only talking about creating your own custom logging, then you need to create a function to run when an error occurs and assign it as the error handler using the set_error_handler() function.
It's important to note that when you use set_error_handler(), you bypass PHP's default error handler entirely. This means that your error_handler level becomes meaningless. All errors, regardless of their severity, will be passed to the error handler function you've created. The first parameter passed to this function by PHP will be the error number, which is the numeric value of the E_xxx constant of the error that was found. You'll need to write custom code to catch only the errors you want.
For example, to catch only E_NOTICE errors, your function would look like this:
function my_error_handler($errno, $errstr, $errfile, $errline) {
if ($errno == E_NOTICE) {
// handle/log the error
}
}
set_error_handler("my_error_handler");
Turns out the system has a custom Apache ErrorLog directive defined, and I have been tail -f ... the default Apache error_log.
Note to self: always check the web server setup first before posting silly questions on SO!
You can create your own handler
<?php
function myErrorHandler($errno, $errstr, $errfile, $errline)
{
if ($errno == E_USER_NOTICE){
/* log actions here */
}
}
set_error_handler("myErrorHandler");
Please tell me if this is correct. In my error handler, I need to be able to detect when the # error-control operator was used to suppress errors, because some external libraries (sadly) use it a lot. Execution of the script should continue, just like when you don't use custom error handlers.
When the at-sign is used, PHP temporarily sets error_reporting to 0. So at the start of a script we set error_reporting to any value but zero - we can now do some beautiful IF/ELSE magic. To avoid any errors being shown at the frontend, we also set display_errors to 0, this will override error_reporting (but we can still use it's value for magic).
<?php
ini_set('display_errors',0);
error_reporting(E_ALL);
function error_handler($errno, $errstr, $errfile, $errline)
{
if (error_reporting()===0) return;
else die();
}
set_error_handler('error_handler');
//This issues an error, but the handler will return and execution continues.
//Remove the at-sign and the script will die()
#file();
echo 'Execution continued, hooray.';
?>
So.. Are there no catches here? Except the one where the external library overrides my error handling.. (any tips on that?)
Considering what your script does, and some user notes on the # operator manual page, it seems what you are doing is OK.
For instance, taras says :
I was confused as to what the # symbol
actually does, and after a few
experiments have concluded the
following:
the error handler that is set gets called regardless of what level the
error reporting is set on, or whether
the statement is preceeded with #
it is up to the error handler to impart some meaning on the different
error levels. You could make your
custom error handler echo all errors,
even if error reporting is set to
NONE.
so what does the # operator do? It temporarily sets the error reporting
level to 0 for that line. If that line
triggers an error, the error handler
will still be called, but it will be
called with an error level of 0
And the set_error_handler manual page seems to confirm that :
Of particular note is that this value will be 0 if the statement
that caused the error was prepended by the # error-control operator.
Here too, there are some user notes that can be useful ; for instance, this one (see the begining of the code)
Still, if what you want is to "disable" the effect of the # operator (not sure I understood the question correctly ; this might help you anyway), to be able to get the error messages while you are on your development environment, you can install the scream extension (pecl, manual)
Provided you configure it the right way, setting this in your php.ini (after installating/loading the extension, of course) :
scream.enabled = 1
This extension will simply disable the # operator.
And here's an example (quoting the manual) :
<?php
// Make sure errors will be shown
ini_set('display_errors', true);
error_reporting(E_ALL);
// Disable scream - this is the default and produce an error
ini_set('scream.enabled', false);
echo "Opening http://example.com/not-existing-file\n";
#fopen('http://example.com/not-existing-file', 'r');
// Now enable scream and try again
ini_set('scream.enabled', true);
echo "Opening http://example.com/not-existing-file\n";
#fopen('http://example.com/another-not-existing-file', 'r');
?>
And this will output :
Opening http://example.com/not-existing-file
Opening http://example.com/not-existing-file
Warning: fopen(http://example.com/another-not-existing-file): failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found in example.php on line 14
I am not sure I would use this extension on a production server (where I never want errors displayed), but it is very useful on a development machine, when using old code, on an application/library that uses # operator extensivly...