Phpgerr unified error handling v0

In general, the unified error handling mechanism is to use [exceptions]. PHP also provides exception functions, but exceptions have requirements on concepts and knowledge, so that they can be used properly. to avoid complexity, therefore, exceptions are not used for unified error handling. website program error handling, the most common is to interrupt program execution... in general, the unified error handling mechanism is to use [exceptions]. PHP also provides exception functions, but exceptions have requirements on concepts and knowledge, so that they can be used properly. to avoid complexity, therefore, exceptions are not used for unified error handling.

The most common error handling method for website programs is to interrupt program execution and display a prompt box to the user. for example, if you use showmessage () in the controller to prompt errors, directly use showmessage () in the controller to prompt.

However, showmessage () is not suitable for class methods and functions, because sometimes the caller needs to handle the error by himself. for example, the error prompt is displayed using the alert () of JS, instead of displaying an html page, you must unify error handling in class methods and functions.

The conservative syntax is that the function returns true or false, and an error message is transmitted by passing an address parameter, for example:

Bool func_name (& $ error)

Class methods define a get_error () method in the class to return the last error message.

However, when an error message can be passed up, it is very troublesome to manually simulate the code to be passed up.

When A website program is called with multiple levels of errors, such as caller> A ()> B ()> C (), an error occurs in the C function, it is very troublesome to pass the error information in this way: B () must handle and be compatible with C (), and A () must be compatible with B.

Only exceptions are self-care. by default, the user is notified and the program execution is interrupted when an error occurs, and the user is allowed to customize how to handle the error.

Therefore, unified error handling means that the user is directly interrupted by default, such as database insertion errors, and allows the caller to customize error handling when needed, such as using JS to pop up error messages.

Therefore, gerr-type unified website program error handling is introduced:

The gerr class is located in/include/gerr. class. php and the class name is gerr. all the methods are static methods and cannot be instantiated.

When an error occurs in a method or function, call gerr: error () to set the error message and return false.

By default, gerr: error () will call showmessge () for error prompt.

When the caller needs to customize error handling, he can call gerr: func_set () to set a custom error handling function, gerr: error () the error handler function set by the caller is called to handle the error.

Generally, the error handling method is determined by the controller, so gerr: func_set () is generally called in the controller. You can use gerr: func_reset () to reset the error handling function to the default function.

In methods and functions, you can use gerr: check () to check whether errors have occurred (generally, program execution is interrupted when errors occur, if the execution is not interrupted, only more errors will occur.) prevent existing errors from being processed.

If the class methods or functions are organized in the form of "flow" (for example, fopen before fwrite), gerr: start () is called at the beginning of the process for gerr to initialize the process, after the process is completed, call gerr: end () to notify gerr that the process has ended.

You can use gerr: get () to obtain the error message.

Example of a function using gerr:

Function myerr () {if (false) {gerr: error ('error occurred ', _ FILE __, _ LINE __, _ FUNCTION __); return false;} return true}

Address:

Reprinted at will, but please attach the article address :-)