PHP error and exception handling

This “small” article is a development of the topic covered in this article.
As you know, PHP was born a long time ago and already then the question arose of what to do with the errors that occurred. Perl, which is the undoubted progenitor of PHP by default, did not have any error handling system. When any error occurred, the server threw out the 500th error and that was it. Therefore, Warnings, Fatal Errors and Notices were a real breakthrough in alleviating the already hard work of a programmer. However, as time went on, the PHP mechanisms did not change, and technologies, as is known, do not like to stand still.

And here in PHP 5.0, finally, in the arsenal of programmers appeared such a powerful tool as an exception or Exception. There are many advantages of Exception, I will describe only a few (perhaps, I express myself inaccurately or even illiterately, but I was just too lazy to look for scientific terms to describe the advantages, because they are described in their own words):

Pass-through generation This means that the occurrence of an exception somewhere in the code will lead to a sequential exit from the control structures and functions before the first catch block or before the main function (with the corresponding error in the stream) of the main script
The ability to override the main class Exception through inheritance
Ability to handle several types of exceptions simultaneously

The handling of standard PHP errors is extremely limited:

You can block with @
You can set your handler with set_error_handler
You can generate your error using trigger_error

It is clear that the standard error handling mechanism is outdated and is present in the language only for compatibility reasons.
In this small article I will try to highlight how error handling can be made universal by transferring it to the use of the exception mechanism.
The main idea: we put our handler for standard errors and throw an exception in it:

<? php
class MyException extends Exception {
public function __construct ($ message, $ errorLevel = 0, $ errorFile = '' , $ errorLine = 0) {
parent :: __ construct ($ message, $ errorLevel);
$ this -> file = $ errorFile;
$ this -> line = $ errorLine;
}
}
set_error_handler ( create_function ( '$ c, $ m, $ f, $ l' , 'throw new MyException ($ m, $ c, $ f, $ l);' ), E_ALL);
?>
* This source code was highlighted with Source Code Highlighter .

This code must be placed in a separate file and connect it only once. The MyException class extends the standard Exception class by adding two additional parameters to the constructor: the file and the line number with an error.
The set_error_handler function sets as an error handler a dynamically created lambda function (callback), which generates an exception in case of an error. I especially ask you to pay attention to the second parameter of the set_error_handler function. This parameter is very important, since it determines for which types of errors a custom (that is, our) handler will be called, and for which standard ones. In this example, I set the value to E_ALL, which means that the handler will be called for all types of errors.
If we do not want to handle some types of errors, for example, Notice, then we can easily indicate this:

set_error_handler ( create_function ( '$ c, $ m, $ f, $ l' , 'throw new MyException ($ m, $ c, $ f, $ l);' ), E_ALL & ~ E_NOTICE); * This source code was highlighted with Source Code Highlighter .

However, the ideal approach, as it seems to me, is the handling of all errors, but for some types, in particular, notice, it would be advisable not to throw an exception, but simply to display information on the screen:

set_error_handler ( create_function ( '$ c, $ m, $ f, $ l' , 'if ($ c === E_NOTICE) {echo' This is notice: '. $ m} else {throw new MyException ($ m, $ c, $ f, $ l);} ' ), E_ALL); * This source code was highlighted with Source Code Highlighter .

Now consider an example close to life. Task:
There is a registration form on the site, it is necessary to implement with the help of exceptions, the processing of validation errors and the issuance of appropriate warnings to the user.
There are actually two difficulties here:

Display all errors at once, not one by one.
Separate validation error handling from other exception handling

Decision:
The main difficulty here for us will be the very notorious advantage of Exception, which is that when throwing an exception, there is a exit from the control structures to the first catch block (or to the end of the script). In order to circumvent this pitfall, we define a new descendant class FormFieldsListException, in which we implement an error accumulation mechanism, and we will only throw an exception after validating all the fields. In the FormFieldsListException class, we define the protected member $ _list in which we will store the data. To simplify working with the $ _list array, we indicate that the class will implement two interfaces: ArrayAccess to access the elements of the array and Iterator to work in a loop. When initializing the validation verification method, we create a FormFieldsListException object, and then, as errors are detected, add them to the FormFieldsListException object, as in a regular array.

<? php
class FormFieldsListException extends Exception implements ArrayAccess, Iterator {
protected $ _list = array ();
public function __construct () {
}
public function offsetExists ($ index) {
return isset ($ this -> _ list [$ index]);
}
public function offsetGet ($ index) {
return $ this -> _ list [$ index];
}
public function offsetSet ($ index, $ value) {
if (isset ($ index)) {
$ this -> _ list [$ index] = $ value;
}
else {
$ this -> _ list [] = $ value;
}
}
public function offsetUnset ($ index) {
unset ($ this -> _ list [$ index]);
}
public function current () {
return current ($ this -> _ list);
}
public function key () {
return key ($ this -> _ list);
}
public function next () {
return next ($ this -> _ list);
}
public function rewind () {
return reset ($ this -> _ list);
}
public function valid () {
return ( bool ) $ this -> current ();
}
}
?>
* This source code was highlighted with Source Code Highlighter .

After the end of the validation procedure, we check if any error messages were entered. If so, we “throw” the prepared exception object.
To catch an exception, we use two catch blocks: for FormFieldsListException and for all other exceptions. This allows you to specify different types of actions when different types of exceptions occur.

<? php
function validateForm () {
$ e = new FormFieldsListException ();
if ($ errorInFirstField) {
$ e [] = 'Error in first field' ;
}
if ($ errorInSecondField) {
$ e [] = 'Error in second field' ;
}
if (( bool ) $ e-> current ()) {
throw $ e;
}
}
try {
validateForm ();
}
catch (FormFieldsListException $ error) {
echo '<b> Errors in the fields </ b>: <br />' ;
foreach ($ error as $ e) {
echo $ e. '<br />' ;
}
}
catch (Exception $ error) {
echo 'Not validation error! ' . $ error-> getMessage ();
}
?>
* This source code was highlighted with Source Code Highlighter .

So here! :)
A properly designed exception system can seriously simplify the programmer’s life, especially when developing applications using the MVC pattern. As a little research has shown, the PHP5 exception handling system carries considerable reserves for upgrading and use in specific situations.
PS : Some of the programmers I showed this article consider the use of exceptions to validate forms, to put it mildly, not the best option (by the way, I would ask readers who are “in the subject” to comment on this), so please consider this example just a learning example, not a guide to action.
PPS : Many thanks to comrade ashofthedream , the dispute with which prompted me to study exceptions in more detail.

UPD : Moved to PHP Blog

Source: https://habr.com/ru/post/30399/

All Articles

PHP error and exception handling

More articles: