PHP error and _php processing summary techniques

With logging, you can send information directly to other log servers, either to a designated email address (or via a mail gateway), or to an operating system log, so that you have the option to record and monitor the most important parts of your application and site.
The error reporting feature allows you to customize the level and type of error feedback, either as a simple hint or with a custom function to process and return information.

Why use error handling?
1. It is the user friendly when the website is wrong
2. Better to avoid errors, debugging, fixing errors
3. Avoid some security risks
4. Better guarantee the robustness of the program
5 .....
First, the simplest error handling ――die ()
Stop running when we anticipate mistakes to occur. For example, when connecting to a database:

Copy Code code as follows:

mysql_connect (' localhost ', ' root ', ' 123456 ') or Die (' Connection Database error: '. mysql_error ());

However, simply terminating the script is not always the right approach.
Ii. custom errors and error triggers
We create an error-handling-specific function that can be called when an error occurs in PHP using the Set_error_handler function setting.

1. Define parameters for error-handling functions:

Parameters	Description
Error_level	Necessary. Sets the error reporting level for user-defined errors. Must be a number of values. See table below: Error reporting level.
Error_message	Necessary. Specify error messages for user-defined errors.
Error_file	Optional. Specify the name of the file in which the error occurred.
Error_line	Optional. The line number that sets the error to occur.
Error_context	Optional. Specify an array that contains each variable that was used when the error occurred and their values.

2. Error basic predefined constants:

value	Constants	Description	Notes
1	E_error (integer)	Fatal Run-time error. Such errors are generally unrecoverable, such as problems caused by memory allocation. The consequence is that the script terminates and no longer continues to run.
2	e_warning (integer)	Runtime Warning (non-fatal error). Only prompts are given, but the script does not terminate the operation.
4	E_parse (integer)	Compile-time syntax parsing error. Parsing errors are generated only by the parser.
8	E_notice (integer)	Run-time notifications. Indicates that the script encounters a situation that may behave incorrectly, but there may be similar notifications in a script that works well.
16	E_core_error (integer)	Fatal error that occurred during PHP initialization startup. The error is similar to E_error, but is generated by the PHP engine core.	Since PHP 4
32	e_core_warning (integer)	A warning (non-fatal error) that occurred during the startup of PHP initialization. Similar to e_warning, but is generated by the PHP engine core.	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)	Compile-time warnings (non-fatal errors). Similar to e_warning, but is generated by the Zend scripting engine.	Since PHP 4
256	E_user_error (integer)	The error message generated by the user. Similar to E_error, but is generated by the user using PHP functions trigger_error () in their code.	Since PHP 4
512	e_user_warning (integer)	A warning message generated by the user. Similar to e_warning, but is generated by the user using PHP functions trigger_error () in their code.	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 PHP functions trigger_error () in their code.	Since PHP 4
2048	e_strict (integer)	Enable PHP to modify your code to make sure that your 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 very dangerous error has occurred, but has not caused the PHP engine to be in an unstable state. If the error is not captured by a user-defined handle (see Set_error_handler ()), it becomes a e_error and the script terminates.	Since PHP 5.2.0
8192	e_deprecated (integer)	Run-time notifications. When enabled, you will be warned about code that might not work correctly in future versions.	Since PHP 5.3.0
16384	e_user_deprecated (integer)	User-produced warning messages. Similar to e_deprecated, but is generated by the user using PHP functions trigger_error () in their code.	Since PHP 5.3.0
30719	E_all (integer)	e_strict All errors and warnings out of the information.	30719 in PHP 5.3.x, 6143 in PHP 5.2.x, 2047 previously

(Level E_error, E_user_error cannot be caught by custom error-handling functions) custom error functions cannot catch fatal error messages because the script stops executing immediately when a fatal run-time error occurs.

3. Trigger Error
The location where the user enters data in the script is useful for triggering errors when the user's input is invalid. In PHP, this task is done by Trigger_error ().
You can trigger an error anywhere in the script, and by adding the second parameter, you can specify the level of error that is triggered.

4. Possible types of errors:

1). E_user_error-Fatal user-generated run-time error. The error cannot be recovered. Script execution was interrupted.
2). E_user_warning-a Non-fatal user-generated run-time warning. Script execution is not interrupted.
3). E_user_notice-Default. User-generated Run-time notifications. The script found a possible error, or it may occur when the script is running normally.
For example:

Copy Code code as follows:

Trigger_error ("Wrong ah", e_user_warning);
Output Warning: Error message in XXXX

Third, error Reporting
By default, PHP sends an error record to the server's error recording system or file, based on the Error_log configuration in php.ini.
By using the Error_log () function, you can send error records to the specified file or remote destination. For example, sending an error message to a mailbox is a good way to do it.
More error handling documents see: http://www.php.net/manual/zh/book.errorfunc.php

Iv. Exception Handling
When the exception is thrown, the subsequent code does not continue, and PHP tries to find a matching "catch" code block.
If the exception is not captured and does not use Set_exception_handler () for the appropriate processing, a serious error (fatal error) occurs, and an error message that outputs "uncaught exception" (no exception is caught) is printed.
1. The processing process shall include:

1.) Try-the function that uses the exception should be in the "try" code block. If no exception is fired, the code continues to execute as usual. However, if the exception is triggered, an exception is thrown.
2.) Throw-here is a rule on how to trigger an exception. Each "throw" must correspond to at least one "catch"
3.) Catch-"catch" blocks of code catch exceptions and create an object that contains exception information

2. Throw the exception again

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

3. Rules of the anomaly

1. Code that requires exception handling should be placed inside the try code 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 blocks to catch different kinds of exceptions.
4. You can throw a (re-thrown) exception again in a catch code block within the try code block.

In short: If an exception is thrown, it must be caught.