Error handling strategy is used to capture the occurrence of a situation that prevents a successful system operation. This can take place at different levels. Low level: a function can receive an unexpected parameter. At a high level, a tool can not accept certain sequence of user actions.
I think it is crucial to distinguish what is a low-level error of an error high level. Each of these errors can take a different course and be reported to the user differently too. If, for some reason, the programmer created a SQL wrong and this prevented a value to be saved in the database, it is not convenient to tell the user that the problem was in SQL, after all, the end user need not (and should not) know what is SQL. However, if the user has filled in a form field with an invalid value, it must be informed in detail about what he missed and/or how to fix.
Using exceptions natives(exception) language PHP is a solution particularly suitable for dealing with low-level errors. In the case of high-level errors, can also be used the same alternative, although I prefer to use methods of input validation of user data and store the error messages in an array (for example). Note that usually in these cases there is no attempt to adjust the invalid value entered by the user, so is the responsibility of the user to correct the problem itself. Already low-level error, you can try to be bypassed in some way (or not).
The operation of exceptions can be relatively simple, but also lets you build solutions rather sophisticated. Don’t intend to discuss the use of exceptions. So, if you want to dig, read the manual:http://www.php.net/manual/en/class.exception.php. If you don’t like to create exception to this and that, maybe it’s a good to know the exceptions defined by SPL: http://www.php.net/manual/en/spl.exceptions.php.
A reasonable solution to error control is to create methods that return Boolean values (true = worked / false = went wrong) and, optionally, the method takes an array of errors that should be passed by reference. Then, if a problem occurs, the array of errors is completed and it will return false.
For errors that should never occur (for example, an error use of a resource by a programmer), it is possible to use exceptions, but can also be used to launch the error log. This is done by the function trigger_error. The function receives a message and an error level. Levels that may be issued by the programmer are:
- E_USER_NOTICE - When you want to send a notification to the programmer (not necessarily an error). For example: a function consumed more memory than expected.
- E_USER_WARNING - When you want to issue a warning to the programmer (a mistake, but not too severe). For example: failing to connect to the database (for some unknown reason), but the page still can be generated with a warning to the end user.
- E_USER_ERROR - When the error is fatal and must stop running the script (the programmer can not launch the system if an error is being caused these). For example, a method needed to receive a mandatory data type, but received another.
- E_USER_DEPRECATED - A special type of warning to indicate that a method is depreciated (should no longer be used and/or has been replaced by a different way to perform the same operation).
There are two functions in PHP especially useful to standardize the flow of processing errors and log unhandled exceptions with try/catch. They are: set_error_handler and set_exception_handler. This makes it possible, for example, store some types of errors in a database to facilitate searches, track the amount in a given period etc..