PHP error and unusual length often handle summary

Logging allows you to selectively record and monitor the most important parts of your application and website by sending messages directly to other logging servers, or to a designated email address (or via a mail gateway), or to the operating system log.
The error reporting feature allows you to customize the level and type of error feedback, either as a simple prompt or by using a custom function to process and return the message.

Why use error handling?
1. Be user-friendly when the site goes wrong
2. Better error avoidance, debugging, and bug fixing
3. Avoid some security risks
4. Better guarantee the robustness of the program
5....
1. The simplest error handling � � die ()
When we anticipate an error, we stop the pace running. For example, when connecting to a database:

mysql_connect('localhost', 'root', '123456') or die (' Error connecting to database: '. mysql_error());

However, simply terminating the script is not always the right approach.
2. Custom errors and error triggers
We create a dedicated error-handling function that, when set with the set_error_handler function, can be called when an error occurs in PHP.

1. Define error handler parameters:
parameter describe error_level A necessity. Specifies the error reporting level for user-defined errors. It has to be one value.

See the table below: Error Reporting Levels.

error_message A necessity. Specifies error messages for user-defined errors. error_file Optional. Specifies the file name in which the error occurred. error_line Optional. Specifies the line number on which the error occurred. error_context Optional. Specify an array containing each variable in use and their values when the error occurs.
2. Error basic predefined constants:
value constant instructions note 1 E_ERROR (integer) Fatal runtime error. This type of error is usually an unrecoverable condition, such as a memory allocation problem. The result is that the script terminates and no longer runs. 2 E_WARNING (integer) Runtime warning (non-fatal error). Only the prompt is given, but the script does not terminate. 4 E_PARSE (integer) Syntax parsing error at compile time. Parsing errors are generated only by the parser. 8 E_NOTICE (integer) Runtime notifications. Indicates that a script may encounter an error, but a similar notification may also occur in a working script. 16 E_CORE_ERROR (integer) A fatal error occurred during PHP initialization startup. This error is similar to E_ERROR, but is caused 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 generated by the PHP engine core. since PHP 4 64 E_COMPILE_ERROR(integer) Fatal compile-time error. Similar to E_ERROR, but generated by the Zend scripting engine. since PHP 4 128 E_COMPILE_WARNING(integer) Compile-time warning (non-fatal error). Similar to E_WARNING, but produced by the Zend scripting engine. since PHP 4 256 E_USER_ERROR (integer) User generated error message. Similar to E_ERROR, but generated by the user himself using the PHP function trigger_error() in the code. since PHP 4 512 E_USER_WARNING(integer) User-generated warning messages. Similar to E_WARNING, but generated by the user himself using the PHP function trigger_error() in the code. since PHP 4 1024 E_USER_NOTICE(integer) User generated notification information. Similar to E_NOTICE, but generated by the user himself using the PHP function trigger_error() in the code. since PHP 4 2048 E_STRICT (integer) Enable PHP's proposed changes to the code to ensure optimal interoperability and forward compatibility. since PHP 5 4096 E_RECOVERABLE_ERROR(integer) Fatal errors that can be caught. It indicates that a potentially dangerous error has occurred, but has not yet caused the ES97en engine to be in an unstable state. If the error is not caught by a user-defined handle (see set_error_handler()), it will be an E_ERROR and the script will terminate. since PHP 5.2.0 8192 E_DEPRECATED (integer) Runtime notifications. Enabled will warn you of code that may not work properly in future versions. since PHP 5.3.0 16384 E_USER_DEPRECATED(integer) The user produces fewer warning messages. Similar to E_DEPRECATED, but generated by the user himself using the PHP function trigger_error() in the code. since PHP 5.3.0 30719 E_ALL (integer) E_STRICT All error and warning messages outside E_STRICT. 30719 in PHP 5.3.x, 6143 in PHP 5.2.x, 2047 previously

(Levels E_ERROR, E_USER_ERROR cannot be caught by custom error handlers.) Custom error functions cannot catch fatal error messages, because the script stops execution immediately when a fatal runtime error occurs.

3. Trigger error
The location of user input data in the script is useful for triggering errors when user input is invalid. In PHP, this task is done by trigger_error().
You can fire an error anywhere in the script, and by adding a second parameter, you can specify the level of error to fire.

4. Possible types of errors:

1).E_USER_ERROR - Fatal user-generated run-time error. The error cannot be recovered. The script execution was interrupted.
2).E_USER_WARNING - Non-lethal user-generated run-time warnings. Script execution is not interrupted.
3).E_USER_NOTICE - Default. User-generated run-time notifications. A possible error was detected by the script, which could have occurred while the script was running normally.
Such as:

trigger_error(" Made a mistake! ", E_USER_WARNING);
//  The output  Warning:  Made a mistake!  in xxxx  Error message of 

3. Error reporting
By default, PHP sends error logs to the server's error logging system or file, according to the error_log configuration in php.ini.
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 an email is a good way to do this.
See more error handling document: http: / / www php. net manual/zh/book errorfunc. php

4. Exception handling
When an exception is thrown, the code that follows does not continue, and PHP tries to find a matching "catch" block.
If the exception is not caught and is not handled with set_exception_handler(), then a critical error (fatal) occurs and the "Uncaught Exception" error message is printed.
1. The processing procedure shall include:

1.) try - Functions that use exceptions should be within the "try" code block. If no exception is raised, the code continues to execute as usual. However, if an exception is raised, an exception is thrown.
2.) throw - This specifies how to raise an exception. There must be at least one catch for every 1 throw
3.) catch - The "catch" block catches the exception and creates an object containing the exception information

2. Rethrow the exception

Sometimes, when an exception is thrown, you might want to handle it differently than the standard. An exception can be thrown again in one "catch" block.
Scripts should hide system errors from the user. System errors may be important to the programmer, but they are not of interest to the user. To make things easier for users, you can again throw an exception with a more user-friendly message.

3. Rules for exceptions

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

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