|
Error Handling and Logging FunctionsThese are functions dealing with error handling and logging. They allow you to define your own error handling rules, as well as modify the way the errors can be logged. This allows you to change and enhance error reporting to suit your needs. With the logging functions, you can send messages directly to other machines, to an email (or email to pager gateway!), to system logs, etc., so you can selectively log and monitor the most important parts of your applications and websites. The error reporting functions allow you to customize what level and kind of error feedback is given, ranging from simple notices to customized functions returned during errors.
The behaviour of these functions is affected by settings in Table 80. Errors and Logging Configuration Options
Here's a short explanation of the configuration directives.
The constants below are always available as part of the PHP core.
Note:
You may use these constant names in Table 81. Errors and Logging
The above values (either numerical or symbolic) are used to build
up a bitmask that specifies which errors to report. You can use the
bitwise operators
to combine these values or mask out certain types of errors. Note
that only '|', '~', '!', '^' and '&' will be understood within
Below we can see an example of using the error handling capabilities in PHP. We define an error handling function which logs the information into a file (using an XML format), and e-mails the developer in case a critical error in the logic happens. Example 589. Using error handling in a script<?php See also syslog(). Table of Contents
Code Examples / Notes » ref.errorfunc21-may-2005 12:20
When configuring your error log file in php.ini, you can use an absolute path or a relative path. A relative path will be resolved based on the location of the generating script, and you'll get a log file in each directory you have scripts in. If you want all your error messages to go to the same file, use an absolute path to the file. In some application development methodologies, there is the concept of an application root directory, indicated by "/" (even on Windows). However, PHP does not seem to have this concept, and using a "/" as the initial character in a log file path produces weird behavior on Windows. If you are running on Windows and have set, in php.ini: error_log = "/php_error.log" You will get some, but not all, error messages. The file will appear at c:\php_error.log and contain internally generated error messages, making it appear that error logging is working. However, log messages requested by error_log() do NOT appear here, or anywhere else, making it appear that the code containing them did not get processed. Apparently on Windows the internally generated errors will interpret "/" as "C:\" (or possibly a different drive if you have Windows installed elsewhere - I haven't tested this). However, the error_log process apparently can't find "/" - understandably enough - and the message is dropped silently. mike
To add to Stephen's note about logging, I found that if I defined the error_log path to be the Apache error log folder (ie: /var/log/httpd/php_error_log), it would still log to Apache's log, not the file I defined. However, as soon as I moved the log to a location outside of the Apache error log folder, Apache obeyed my php.ini setting and began logging to the file I defined (ie: /var/log/php/php_error_log). Platform: RHEL 4, Apache 2.0.55, PHP 5.2.2 giunta dot gaetano
Something to take care of: if track_errors is enabled, $php_errormsg will always be populated with error messages of warning (and possibly notice?) level, regardless of the error_reporting level set.
ptah
PHP5 only (only tested with php5.0). If you, for some reason, prefer exceptions over errors and have your custom error handler (set_error_handler) wrap the error into an exception you have to be careful with your script. Because if you, instead of just calling the exception handler, throws the exception, and having a custom exception handler (set_exception_handler). And an error is being triggered inside that exception handler, you will get a weird error: "Fatal error: Exception thrown without a stack frame in Unknown on line 0" This error is not particulary informative, is it? :) This example below will cause this error. <?php class PHPErrorException extends Exception { private $context = null; public function __construct ($code, $message, $file, $line, $context = null) { parent::__construct($message, $code); $this->file = $file; $this->line = $line; $this->context = $context; } }; function error_handler($code, $message, $file, $line) { throw new PHPErrorException($code, $message, $file, $line); } function exception_handler(Exception $e) { $errors = array( E_USER_ERROR => "User Error", E_USER_WARNING => "User Warning", E_USER_NOTICE => "User Notice", ); echo $errors[$e->getCode()].': '.$e->getMessage().' in '.$e->getFile(). ' on line '.$e->getLine()."\n"; echo $e->getTraceAsString(); } set_error_handler('error_handler'); set_exception_handler('exception_handler'); // Throw exception with an /unkown/ error code. throw new Exception('foo', 0); ?> There are however, easy fix for this as it's only cause is sloppy code. Like one, directly call exception_handler from error_handler instead of throwing an exception. Not only does it remedy this problem, but it's also faster. Though this will cause a `regular` unhandled exception being printed and if only "designed" error messages are intended, this is not the ultimate solution. So, what is there to do? Make sure the code in exception_handlers doesn't cause any errors! In this case a simple isset() would have solved it. regards, C-A B. mortonda
Note the example code listed here calls date() every time this is called. If you have a complex source base which calls the custom error handler often, it can end up taking quite a bit of time. I ran a profiler on som code and discovered that 50% of the time was spent in the date function in this error handler.
theotek
It is totally possible to use debug_backtrace() inside an error handling function. Here, take a look: <?php set_error_handler('errorHandler'); function errorHandler( $errno, $errstr, $errfile, $errline, $errcontext) { echo 'Into '.__FUNCTION__.'() at line '.__LINE__. "\n\n---ERRNO---\n". print_r( $errno, true). "\n\n---ERRSTR---\n". print_r( $errstr, true). "\n\n---ERRFILE---\n". print_r( $errfile, true). "\n\n---ERRLINE---\n". print_r( $errline, true). "\n\n---ERRCONTEXT---\n".print_r( $errcontext, true). "\n\nBacktrace of errorHandler()\n". print_r( debug_backtrace(), true); } function a( ) { //echo "a()'s backtrace\n".print_r( debug_backtrace(), true); asdfasdf; // oops } function b() { //echo "b()'s backtrace\n".print_r( debug_backtrace(), true); a(); } b(); ?> Outputs: <raw> Into errorhandler() at line 9 ---ERRNO--- 8 ---ERRSTR--- Use of undefined constant asdfasdf - assumed 'asdfasdf' ---ERRFILE--- /home/theotek/test-1.php ---ERRLINE--- 23 ---ERRCONTEXT--- Array ( ) Backtrace of errorHandler() Array ( [0] => Array ( [function] => errorhandler [args] => Array ( [0] => 8 [1] => Use of undefined constant asdfasdf - assumed 'asdfasdf' [2] => /home/theotek/test-1.php [3] => 23 [4] => Array ( ) ) ) [1] => Array ( [file] => /home/theotek/test-1.php [line] => 23 [function] => a ) [2] => Array ( [file] => /home/theotek/test-1.php [line] => 30 [function] => a [args] => Array ( ) ) [3] => Array ( [file] => /home/theotek/test-1.php [line] => 33 [function] => b [args] => Array ( ) ) ) </raw> So, the first member of the backtrace's array is not really surprising, except from the missing "file" and "line" members. The second member of the backtrace seem the be a hook inside the zend engine that is used to trigger the error. Other members are the normal backtrace. tswaesch
In Addition to the hint according error_reporting and display_errors in case that there is a global restriction that prevents showing the errors. I tried the example of "petrov dot michael () gmail com" like this <?php ini_set('display_errors','1'); ini_set('display_startup_errors','1'); error_reporting (E_ALL); include('index.php'); ?> and it works great, but first I tried it without using the "include"-part. I pasted all at the beginning of my index.php and started it. This will NOT work. Its highly IMPORTANT that the code to prove is included afterwards. Hope it helps to prevent more #?!@%! errors. :-)= email_php_28429
if you cannot use php 5+ and if you do not know, when your administrator/provider will update to a newer php-version, this could be interesting. otherwise it surely is not. ;-) if you use the example above "example 1: using error handling in a script" with a php version prior to php 5, the part <?php $errortype = array( // ... E_STRICT => "Runtime Notice");?> will throw a notice like "Use of undefined constant E_STRICT - assumed 'E_STRICT'". of course one could avoid this problem, with <?php if(defined('E_STRICT')) define('E_STRICT', 2048); ?>. but this _could_ generate problems in future versions of php, if E_STRICT is set to 42 or something else. for this reason i suggest <?php $errortype = array( E_ERROR => 'error', E_WARNING => 'warning', E_PARSE => 'parsing error', E_NOTICE => 'notice', E_CORE_ERROR => 'core error', E_CORE_WARNING => 'core warning', E_COMPILE_ERROR => 'compile error', E_COMPILE_WARNING => 'compile warning', E_USER_ERROR => 'user error', E_USER_WARNING => 'user warning', E_USER_NOTICE => 'user notice'); if(defined('E_STRICT')) $errortype[E_STRICT] = 'runtime notice'; ?>. <?php // and instead of // error_reporting(E_ALL | E_STRICT); // one can use error_reporting(E_ALL | (defined('E_STRICT')? E_STRICT : 0)); // to avoid that notice. ?> prosit seth stephen
If you are using PHP as an Apache module, your default behavior may be to write PHP error messages to Apache's error log. This is because the error_log .ini directive may be set equal to "error_log" which is also the name of Apache's error log. I think this is intentional. However, you can separate Apache errors from PHP errors if you wish by simply setting a different value for error_log. I write mine in the /var/log folder. tracerdx
I keep seeing qualification lists for error types/error-nums as arrays; In user notes and in the manual itself. For example, in this manual entry's example, when trying to seperate behavior for the variable trace in the error report: <?php //... // set of errors for which a var trace will be saved $user_errors = array(E_USER_ERROR, E_USER_WARNING, E_USER_NOTICE); //and later... if (in_array($errno, $user_errors)) { //...whatever } //... ?> I was under the impression that PHP error code values where bitwise flag values. Wouldn't bitwise masking be better? So I propose a slightly better way: <?php //... $user_errors = E_USER_ERROR | E_USER_WARNING | E_USER_NOTICE; //...blah... if ($errno & $user_errors) { //...whatever } //... ?> Or for those of you who don't like the idea of using an integer as the condition in an if statement: <?php if (($errno & $user_errors) > 0) { //...whatever } ?> I think that's much more efficient than using _yet another_ array() constuct and an in_array(). If I am wrong, and the E_* constants aren't supposed to be used in this fashion (ie, the constans aren't guaranteed to be bitwise, which would be odd since that's how they're setup in the php.ini file), then delete me. I just don't see why one should be using arrays when bitwise comparisons will work, considering the bitwise method should be MUCH more efficient. petrov dot michael gmail com
I have found that on servers that enforce display_errors to be off it is very inconvenient to debug syntax errors since they cause fatal startup errors. I have used the following method to bypass this limitation: The syntax error is inside the file "syntax.php", therefore I create a file "syntax.debug.php" with the following code: <?php error_reporting(E_ALL); ini_set('display_errors','On'); include('syntax.php'); ?> The 5 line file is guaranteed to be free of errors, allowing PHP to execute the directives within it before including the file which previously caused fatal startup errors. Now those fatal startup errors become run time fatal errors. omega172
As pointed out previously, PHP by default logs to the Apache ErrorLog. Beware: the messages it logs do not conform to Apache's error log format (missing date and severity fields), so if you use an automated parser on your error logs, you'll want to redirect PHP's errors somewhere else with the error_log directive. shawing
Although the root user writes to the files 'error_log' and 'access_log', the Apache user has to own the file referenced by 'error_log = filename' or no log entries will be written. ; From php.ini ; Log errors to specified file. error_log = /usr/local/apache/logs/php.errors [root@www logs]$ ls -l /usr/local/apache/logs/php.errors -rw-r--r-- 1 nobody root 27K Jan 27 16:58 php.errors pgerzsonr
A handy errorhandler class can be found at: http://phpclasses.upperdesign.com/browse.html/package/345 It has several enhancements (report layouts): * prints the source code fragment where the error encountered, * prints variable context around error source, * suppresses error-messages, instead displays an arbitrary HTML or PHP page * logging to multiple targets and autodetecting target logging * error messages can be displayed in a separate browser window * catching errors for runtime generated codes * debugging variables. |
Change Language.NET Functions Apache-specific Functions Alternative PHP Cache Advanced PHP debugger Array Functions Aspell functions [deprecated] BBCode Functions BCMath Arbitrary Precision Mathematics Functions PHP bytecode Compiler Bzip2 Compression Functions Calendar Functions CCVS API Functions [deprecated] Class/Object Functions Classkit Functions ClibPDF Functions [deprecated] COM and .Net (Windows) Crack Functions Character Type Functions CURL Cybercash Payment Functions Credit Mutuel CyberMUT functions Cyrus IMAP administration Functions Date and Time Functions DB++ Functions Database (dbm-style) Abstraction Layer Functions dBase Functions DBM Functions [deprecated] dbx Functions Direct IO Functions Directory Functions DOM Functions DOM XML Functions enchant Functions Error Handling and Logging Functions Exif Functions Expect Functions File Alteration Monitor Functions Forms Data Format Functions Fileinfo Functions filePro Functions Filesystem Functions Filter Functions Firebird/InterBase Functions Firebird/Interbase Functions (PDO_FIREBIRD) FriBiDi Functions FrontBase Functions FTP Functions Function Handling Functions GeoIP Functions Gettext Functions GMP Functions gnupg Functions Net_Gopher Haru PDF Functions hash Functions HTTP Hyperwave Functions Hyperwave API Functions i18n Functions IBM Functions (PDO_IBM) IBM DB2 iconv Functions ID3 Functions IIS Administration Functions Image Functions Imagick Image Library IMAP Informix Functions Informix Functions (PDO_INFORMIX) Ingres II Functions IRC Gateway Functions PHP / Java Integration JSON Functions KADM5 LDAP Functions libxml Functions Lotus Notes Functions LZF Functions Mail Functions Mailparse Functions Mathematical Functions MaxDB PHP Extension MCAL Functions Mcrypt Encryption Functions MCVE (Monetra) Payment Functions Memcache Functions Mhash Functions Mimetype Functions Ming functions for Flash Miscellaneous Functions mnoGoSearch Functions Microsoft SQL Server Functions Microsoft SQL Server and Sybase Functions (PDO_DBLIB) Mohawk Software Session Handler Functions mSQL Functions Multibyte String Functions muscat Functions MySQL Functions MySQL Functions (PDO_MYSQL) MySQL Improved Extension Ncurses Terminal Screen Control Functions Network Functions Newt Functions NSAPI-specific Functions Object Aggregation/Composition Functions Object property and method call overloading Oracle Functions ODBC Functions (Unified) ODBC and DB2 Functions (PDO_ODBC) oggvorbis OpenAL Audio Bindings OpenSSL Functions Oracle Functions [deprecated] Oracle Functions (PDO_OCI) Output Control Functions Ovrimos SQL Functions Paradox File Access Parsekit Functions Process Control Functions Regular Expression Functions (Perl-Compatible) PDF Functions PDO Functions Phar archive stream and classes PHP Options&Information POSIX Functions Regular Expression Functions (POSIX Extended) PostgreSQL Functions PostgreSQL Functions (PDO_PGSQL) Printer Functions Program Execution Functions PostScript document creation Pspell Functions qtdom Functions Radius Rar Functions GNU Readline GNU Recode Functions RPM Header Reading Functions runkit Functions SAM - Simple Asynchronous Messaging Satellite CORBA client extension [deprecated] SCA Functions SDO Functions SDO XML Data Access Service Functions SDO Relational Data Access Service Functions Semaphore SESAM Database Functions PostgreSQL Session Save Handler Session Handling Functions Shared Memory Functions SimpleXML functions SNMP Functions SOAP Functions Socket Functions Standard PHP Library (SPL) Functions SQLite Functions SQLite Functions (PDO_SQLITE) Secure Shell2 Functions Statistics Functions Stream Functions String Functions Subversion Functions Shockwave Flash Functions Swish Functions Sybase Functions TCP Wrappers Functions Tidy Functions Tokenizer Functions Unicode Functions URL Functions Variable Handling Functions Verisign Payflow Pro Functions vpopmail Functions W32api Functions WDDX Functions win32ps Functions win32service Functions xattr Functions xdiff Functions XML Parser Functions XML-RPC Functions XMLReader functions XMLWriter Functions XSL functions XSLT Functions YAZ Functions YP/NIS Functions Zip File Functions Zlib Compression Functions |