PHP error and differential long processing summary

PHP provides error handling and logging functions. These functions allow you to define your own error handling rules and modify the way errors are recorded. In this way, you can change and enhance the error output information according to your needs to meet actual needs

With the logging function, you can send information directly to other log servers, or to a designated email address (or through a mail gateway), or to the operating system log, etc., so you can selectively record and monitor your application The most important part of the program and website. The error report function allows you to customize the level and type of error feedback. It can be a simple prompt message or use a custom function to process and return information.

 Why use error handling?
1. Is user friendly when the website goes wrong
 2. Better avoid errors, debug, and fix errors
3. Avoid some security risks
4. Better guarantee the robustness of the program
5 .......

First, the simplest error handling-die ()
When we expect an error, stop running. For example, when connecting to a database: The code is as follows: mysql_connect ('localhost', 'root', '123456') or die ('Connection to database error:'. Mysql_error ()); However, simply terminating the script is not always the appropriate way .

Custom errors and error triggers
We create a special error handling function, which can be called when an error occurs in PHP after it is set using the set_error_handler function.

 1. Define the parameters of the error handling function:
 Parameter Description error_level Required. Specifies the level of error reporting for user-defined errors. Must be a number. See the table below: Error Reporting Level. error_message Required. Specifies error messages for user-defined errors. error_file Optional. Specifies the name of the file in which the error occurred. error_line Optional. Specifies the line number where the error occurred. error_context Optional. Specifies an array containing each variable and their values used when the error occurred.

   2. Error basic predefined constants:
 Value Constant Description Remarks 1 E_ERROR (integer) Fatal runtime error. This type of error is usually an unrecoverable situation, such as a problem caused by memory allocation. The consequence is that the script terminates and no longer runs. 2 E_WARNING (integer) Runtime warning (non-fatal error). Only prompts are given, but the script does not terminate. 4 E_PARSE (integer) Compile time parsing error. Parsing errors are only generated by the parser. 8 E_NOTICE (integer) Runtime notification. Indicates that the script may encounter an error situation, but a similar notification may be available in a script that can run normally. 16 E_CORE_ERROR (integer) Fatal error occurred during PHP initialization startup. This error is similar to E_ERROR, but is generated by the PHP engine core. since PHP 4 32 E_CORE_WARNING (integer) Warning (non-fatal error) that occurred during PHP initialization startup. Similar to E_WARNING, but is generated by the core of the PHP engine. since PHP 4 64 E_COMPILE_ERROR (integer) Fatal compile-time error. Similar to E_ERROR, but is generated by the Zend scripting engine. since PHP 4 128 E_COMPILE_WARNING (integer) Warning at compile time (non-fatal error). Similar to E_WARNING, but is generated by the Zend scripting engine. since PHP 4 256 E_USER_ERROR (integer) User generated error message. Similar to E_ERROR, but is generated by the user using the PHP function trigger_error () in the code itself. since PHP 4 512 E_USER_WARNING (integer) Warning message generated by the user. Similar to E_WARNING, but generated by the user using the PHP function trigger_error () in the code itself. since PHP 4 1024 E_USER_NOTICE (integer) Notification information generated by the user. Similar to E_NOTICE, but is generated by the user using the PHP function trigger_error () in the code itself. since PHP 4 2048 E_STRICT (integer) Enables PHP code modification suggestions to ensure the code has the best interoperability and forward compatibility. since PHP 5 4096 E_RECOVERABLE_ERROR (integer) Fatal error that can be caught. It indicates that a potentially dangerous error has occurred, but it has not caused the PHP engine to be unstable. If the error is not caught by a user-defined handle (see set_error_handler ()), it will become an E_ERROR and the script will terminate. since PHP 5.2.0 8192 E_DEPRECATED (integer) Runtime notification. When enabled, warns of code that may not work in future releases. since PHP 5.3.0 16384 E_USER_DEPRECATED (integer) Warning message generated by the user. Similar to E_DEPRECATED, but is generated by the user using the PHP function trigger_error () in the code itself. since PHP 5.3.0 30719 E_ALL (integer) E_STRICT all errors and warnings. 30719 in PHP 5.3.x, 6143 in PHP 5.2.x, 2047 previously (levels E_ERROR, E_USER_ERROR cannot be captured by custom error handling functions) Fatal error messages cannot be captured in custom error functions, because fatal operations occur When an error occurs, the script stops execution immediately.

 3. Trigger error Where the user enters data in the script, it is useful to trigger an error when the user's input is invalid. In PHP, this task is done by trigger_error (). You can trigger errors anywhere in the script, and by adding a second parameter, you can specify the level of errors that are triggered.

4. Possible error types:
1) .E_USER_ERROR-Fatal user-generated run-time error. The error cannot be recovered. Script execution was interrupted.
2) .E_USER_WARNING-non-fatal user-generated run-time warning. Script execution is not interrupted.
 3) .E_USER_NOTICE-default. User-generated run-time notification. The script found a possible error, or it could happen when the script was running normally. For example: The code is as follows: trigger_error ("An error has occurred", E_USER_WARNING); // Output Warning: An error occurred in xxxx error message

  Third, the error report
 By default, according to the error_log configuration in php.ini, PHP sends error logs to the server's error logging system or file. By using the error_log () function, you can send an error log to a specified file or remote destination. For example, sending an error message to a mailbox is a good way. For more error handling documentation, see: http://www.php.net/manual/en/book.errorfunc.php

Fourth, exception handling
 When an exception is thrown, the subsequent code will not continue executing, and PHP will try to find a matching "catch" code block. If the exception is not caught and you do not use set_exception_handler () to handle it accordingly, then a serious error (fatal error) will occur and an "Uncaught Exception" error message will be output.

 1. Processing procedures should include:
1.) try-Functions that use exceptions should be inside a "try" code block. If no exception is triggered, the code will continue execution as usual. But if an exception is triggered, an exception is thrown.
 2.) throw-This specifies how to trigger an exception. Each "throw" must correspond to at least one "catch" 3.) catch-The "catch" code block will catch the exception and create an object containing the exception information

 2. Rethrowing an Exception Sometimes, when an exception is thrown, you may want to handle it in a different way than the standard. Exceptions can be thrown again in a "catch" code block. The script should hide system errors from the user. System errors may be important to programmers, but users are not interested in them. To make it easier for users, you can throw an exception again with a user-friendly message.

 3. Anomalous rules
1). The code that needs exception handling should be placed in a try block to catch potential exceptions.
2). Each try or throw code block must have at least one corresponding catch code block.
 3). Use multiple catch code blocks to catch different kinds of exceptions.
4). You can throw (re-thrown) the exception again in the catch block inside the try block. In short: if an exception is thrown, you must catch it.