Как правильно обрабатывать ошибки php

Исключения

Содержание

  • Наследование исключений

В PHP реализована модель исключений, аналогичная тем, что используются в других языках программирования.
Исключение в PHP может быть выброшено (throw) и поймано (catch).
Код может быть заключён в блок try, чтобы облегчить обработку потенциальных исключений.
У каждого блока try должен быть как минимум один соответствующий блок catch или finally.

Если выброшено исключение, а в текущей области видимости функции нет блока catch,
исключение будет «подниматься» по стеку вызовов к вызывающей функции, пока не найдёт подходящий блок catch.
Все блоки finally, которые встретятся на этом пути, будут выполнены.
Если стек вызовов разворачивается до глобальной области видимости, не встречая подходящего блока catch,
программа завершается с неисправимой ошибкой, если не был установлен глобальный обработчик исключений.

Выброшенный объект должен наследовать (instanceof) интерфейс Throwable.
Попытка выбросить объект, который таковым не является, приведёт к неисправимой ошибке PHP.

Начиная с PHP 8.0.0, ключевое слово throw является выражением и может быть использовано
в любом контексте выражения. В предыдущих версиях оно было утверждением
и должно было располагаться в отдельной строке.

catch

Блок catch определяет, как реагировать на выброшенное исключение.
Блок catch определяет один или несколько типов исключений или ошибок, которые он может обработать,
и, по желанию, переменную, которой можно присвоить исключение
(указание переменной было обязательно до версии PHP 8.0.0).
Первый блок catch, с которым столкнётся выброшенное исключение или ошибка
и соответствует типу выброшенного объекта, обработает объект.

Несколько блоков catch могут быть использованы для перехвата различных классов исключений.
Нормальное выполнение (когда исключение не выброшено в блоке try)
будет продолжаться после последнего блока catch, определённого в последовательности.
Исключения могут быть выброшены (throw) (или повторно выброшены) внутри блока catch.
В противном случае выполнение будет продолжено после блока catch, который был вызван.

При возникновении исключения, код, следующий за утверждением, не будет выполнен,
а PHP попытается найти первый подходящий блок catch.
Если исключение не поймано, будет выдана неисправимая ошибка PHP
с сообщением «Uncaught Exception ...«,
если только обработчик не был определён с помощью функции set_exception_handler().

Начиная с версии PHP 7.1.0, в блоке catch можно указывать несколько исключений,
используя символ |. Это полезно, когда разные исключения
из разных иерархий классов обрабатываются одинаково.

Начиная с версии PHP 8.0.0, имя переменной для пойманного исключения является необязательным.
Если оно не указано, блок catch будет выполнен,
но не будет иметь доступа к выброшенному объекту.

finally

Блок finally также может быть указан после или вместо блоков catch.
Код в блоке finally всегда будет выполняться после блоков try и catch,
независимо от того, было ли выброшено исключение
и до возобновления нормального выполнения.

Одно из заметных взаимодействий происходит между блоком finally и оператором return.
Если оператор return встречается внутри блоков try или catch, блок finally
всё равно будет выполнен. Более того, оператор return выполнится, когда встретится,
но результат будет возвращён после выполнения блока finally.
Кроме того, если блок finally также содержит оператор return,
возвращается значение из блока finally.

Глобальный обработчик исключений

Если исключению разрешено распространяться на глобальную область видимости,
оно может быть перехвачено глобальным обработчиком исключений, если он установлен.
Функция set_exception_handler() может задать функцию,
которая будет вызвана вместо блока catch, если не будет вызван никакой другой блок.
Эффект по сути такой же, как если бы вся программа была обёрнута в блок try—catch
с этой функцией в качестве catch.

Примечания

Замечание:

Внутренние функции PHP в основном используют отчёт об ошибках,
только современные объектно-ориентированные модули используют исключения.
Однако ошибки можно легко перевести в исключения с помощью класса ErrorException.
Однако эта техника работает только с исправляемыми ошибками.

Пример #1 Преобразование отчётов об ошибках в исключения


<?php
function exceptions_error_handler($severity, $message, $filename, $lineno) {
throw new ErrorException($message, 0, $severity, $filename, $lineno);
}set_error_handler('exceptions_error_handler');
?>

Примеры

Пример #2 Выбрасывание исключения


<?php
function inverse($x) {
if (!$x) {
throw new Exception('Деление на ноль.');
}
return 1/$x;
}

try {
echo

inverse(5) . "n";
echo inverse(0) . "n";
} catch (Exception $e) {
echo 'Выброшено исключение: ', $e->getMessage(), "n";
}// Продолжение выполнения
echo "Привет, мирn";
?>

Результат выполнения данного примера:

0.2
Выброшено исключение: Деление на ноль.
Привет, мир

Пример #3 Обработка исключений с помощью блока finally


<?php
function inverse($x) {
if (!$x) {
throw new Exception('Деление на ноль.');
}
return 1/$x;
}

try {
echo

inverse(5) . "n";
} catch (Exception $e) {
echo 'Поймано исключение: ', $e->getMessage(), "n";
} finally {
echo "Первый блок finally.n";
}

try {
echo

inverse(0) . "n";
} catch (Exception $e) {
echo 'Поймано исключение: ', $e->getMessage(), "n";
} finally {
echo "Второй блок finally.n";
}// Продолжение нормального выполнения
echo "Привет, мирn";
?>

Результат выполнения данного примера:

0.2
Первый блок finally.
Поймано исключение: Деление на ноль.
Второй блок finally.
Привет, мир

Пример #4 Взаимодействие между блоками finally и return


<?phpfunction test() {
try {
throw new Exception('foo');
} catch (Exception $e) {
return 'catch';
} finally {
return 'finally';
}
}

echo

test();
?>

Результат выполнения данного примера:

Пример #5 Вложенные исключения


<?phpclass MyException extends Exception { }

class

Test {
public function testing() {
try {
try {
throw new MyException('foo!');
} catch (MyException $e) {
// повторный выброс исключения
throw $e;
}
} catch (Exception $e) {
var_dump($e->getMessage());
}
}
}$foo = new Test;
$foo->testing();?>

Результат выполнения данного примера:

Пример #6 Обработка нескольких исключений в одном блоке catch


<?phpclass MyException extends Exception { }

class

MyOtherException extends Exception { }

class

Test {
public function testing() {
try {
throw new MyException();
} catch (MyException | MyOtherException $e) {
var_dump(get_class($e));
}
}
}$foo = new Test;
$foo->testing();?>

Результат выполнения данного примера:

Пример #7 Пример блока catch без указания переменной

Допустимо начиная с PHP 8.0.0


<?phpclass SpecificException extends Exception {}

function

test() {
throw new SpecificException('Ой!');
}

try {

test();
} catch (SpecificException) {
print "Было поймано исключение SpecificException, но нам безразлично, что у него внутри.";
}
?>

Пример #8 Throw как выражение

Допустимо начиная с PHP 8.0.0


<?phpfunction test() {
do_something_risky() or throw new Exception('Всё сломалось');
}

try {

test();
} catch (Exception $e) {
print $e->getMessage();
}
?>

ask at nilpo dot com

14 years ago


If you intend on creating a lot of custom exceptions, you may find this code useful.  I've created an interface and an abstract exception class that ensures that all parts of the built-in Exception class are preserved in child classes.  It also properly pushes all information back to the parent constructor ensuring that nothing is lost.  This allows you to quickly create new exceptions on the fly.  It also overrides the default __toString method with a more thorough one.

<?php
interface IException
{
    /* Protected methods inherited from Exception class */
    public function getMessage();                 // Exception message
    public function getCode();                    // User-defined Exception code
    public function getFile();                    // Source filename
    public function getLine();                    // Source line
    public function getTrace();                   // An array of the backtrace()
    public function getTraceAsString();           // Formated string of trace

        /* Overrideable methods inherited from Exception class */

public function __toString();                 // formated string for display
    public function __construct($message = null, $code = 0);
}

abstract class

CustomException extends Exception implements IException
{
    protected $message = 'Unknown exception';     // Exception message
    private   $string;                            // Unknown
    protected $code    = 0;                       // User-defined exception code
    protected $file;                              // Source filename of exception
    protected $line;                              // Source line of exception
    private   $trace;                             // Unknownpublic function __construct($message = null, $code = 0)
    {
        if (!$message) {
            throw new $this('Unknown '. get_class($this));
        }
        parent::__construct($message, $code);
    }

        public function

__toString()
    {
        return get_class($this) . " '{$this->message}' in {$this->file}({$this->line})n"
                                . "{$this->getTraceAsString()}";
    }
}
?>

Now you can create new exceptions in one line:

<?php
class TestException extends CustomException {}
?>

Here's a test that shows that all information is properly preserved throughout the backtrace.

<?php
function exceptionTest()
{
    try {
        throw new TestException();
    }
    catch (TestException $e) {
        echo "Caught TestException ('{$e->getMessage()}')n{$e}n";
    }
    catch (Exception $e) {
        echo "Caught Exception ('{$e->getMessage()}')n{$e}n";
    }
}

echo

'<pre>' . exceptionTest() . '</pre>';
?>

Here's a sample output:

Caught TestException ('Unknown TestException')
TestException 'Unknown TestException' in C:xampphtdocsCustomExceptionCustomException.php(31)
#0 C:xampphtdocsCustomExceptionExceptionTest.php(19): CustomException->__construct()
#1 C:xampphtdocsCustomExceptionExceptionTest.php(43): exceptionTest()
#2 {main}


Johan

12 years ago


Custom error handling on entire pages can avoid half rendered pages for the users:

<?php
ob_start();
try {
    /*contains all page logic
    and throws error if needed*/
    ...
} catch (Exception $e) {
  ob_end_clean();
  displayErrorPage($e->getMessage());
}
?>


christof+php[AT]insypro.com

5 years ago


In case your E_WARNING type of errors aren't catchable with try/catch you can change them to another type of error like this:

<?php
    set_error_handler(function($errno, $errstr, $errfile, $errline){
            if($errno === E_WARNING){
                // make it more serious than a warning so it can be caught
                trigger_error($errstr, E_ERROR);
                return true;
            } else {
                // fallback to default php error handler
                return false;
            }
    });

    try {

// code that might result in a E_WARNING
    } catch(Exception $e){
            // code to handle the E_WARNING (it's actually changed to E_ERROR at this point)
    } finally {
            restore_error_handler();
    }
?>


lscorionjs at gmail dot com

4 months ago


<?phptry {
  $str = 'hi';
  throw new Exception();
} catch (Exception) {
  var_dump($str);
} finally {
  var_dump($str);
}?>

Output:
string(2) "hi"
string(2) "hi"

Shot (Piotr Szotkowski)

14 years ago


‘Normal execution (when no exception is thrown within the try block, *or when a catch matching the thrown exception’s class is not present*) will continue after that last catch block defined in sequence.’

‘If an exception is not caught, a PHP Fatal Error will be issued with an “Uncaught Exception …” message, unless a handler has been defined with set_exception_handler().’

These two sentences seem a bit contradicting about what happens ‘when a catch matching the thrown exception’s class is not present’ (and the second sentence is actually correct).


Simo

8 years ago


#3 is not a good example. inverse("0a") would not be caught since (bool) "0a" returns true, yet 1/"0a" casts the string to integer zero and attempts to perform the calculation.

daviddlowe dot flimm at gmail dot com

5 years ago


Starting in PHP 7, the classes Exception and Error both implement the Throwable interface. This means, if you want to catch both Error instances and Exception instances, you should catch Throwable objects, like this:

<?phptry {
    throw new Error( "foobar" );
    // or:
    // throw new Exception( "foobar" );
}
catch (Throwable $e) {
    var_export( $e );
}?>


Edu

9 years ago


The "finally" block can change the exception that has been throw by the catch block.

<?php
try{
        try {
                throw new Exception("Hello");
        } catch(Exception $e) {
                echo $e->getMessage()." catch inn";
                throw $e;
        } finally {
                echo $e->getMessage()." finally n";
                throw new Exception("Bye");
        }
} catch (Exception $e) {
        echo $e->getMessage()." catch outn";
}
?>

The output is:

Hello catch in
Hello finally
Bye catch out


mlaopane at gmail dot com

5 years ago


<?php/**
* You can catch exceptions thrown in a deep level function
*/function employee()
{
    throw new Exception("I am just an employee !");
}

function

manager()
{
    employee();
}

function

boss()
{
    try {
        manager();
    } catch (Exception $e) {
        echo $e->getMessage();
    }
}boss(); // output: "I am just an employee !"

telefoontoestel at nospam dot org

8 years ago


When using finally keep in mind that when a exit/die statement is used in the catch block it will NOT go through the finally block.

<?php
try {
    echo "try block<br />";
    throw new Exception("test");
} catch (Exception $ex) {
    echo "catch block<br />";
} finally {
    echo "finally block<br />";
}// try block
// catch block
// finally block
?>

<?php
try {
    echo "try block<br />";
    throw new Exception("test");
} catch (Exception $ex) {
    echo "catch block<br />";
    exit(1);
} finally {
    echo "finally block<br />";
}// try block
// catch block
?>


Tom Polomsk

8 years ago


Contrary to the documentation it is possible in PHP 5.5 and higher use only try-finally blocks without any catch block.

Sawsan

11 years ago


the following is an example of a re-thrown exception and the using of getPrevious function:

<?php

$name

= "Name";//check if the name contains only letters, and does not contain the word nametry
   {
   try
     {
      if (preg_match('/[^a-z]/i', $name))
       {
           throw new Exception("$name contains character other than a-z A-Z");
       }  
       if(strpos(strtolower($name), 'name') !== FALSE)
       {
          throw new Exception("$name contains the word name");
       }
       echo "The Name is valid";
     }
   catch(Exception $e)
     {
     throw new Exception("insert name again",0,$e);
     }
   }

catch (

Exception $e)
   {
   if ($e->getPrevious())
   {
    echo "The Previous Exception is: ".$e->getPrevious()->getMessage()."<br/>";
   }
   echo "The Exception is: ".$e->getMessage()."<br/>";
   }?>


ilia-yats at ukr dot net

5 months ago


Note some undocumented details about exceptions thrown from 'finally' blocks.

When exception is thrown from 'finally' block, it overrides the original not-caught (or re-thrown) exception. So the behavior is similar to 'return': value returned from 'finally' overrides the one returned earlier. And the original exception is automatically appended to the exceptions chain, i.e. becomes 'previous' for the new one. Example:
<?php
try {
    try {
        throw new Exception('thrown from try');
    } finally {
        throw new Exception('thrown from finally');
    }
} catch(Exception $e) {
    echo $e->getMessage();
    echo PHP_EOL;
    echo $e->getPrevious()->getMessage();
} // will output:
// thrown from finally
// thrown from try
?>

Example with re-throwing:
<?php
try {
    try {
        throw new Exception('thrown from try');
    } catch (Exception $e) {
        throw new Exception('thrown from catch');
    } finally {
        throw new Exception('thrown from finally');
    }
} catch(Exception $e) {
    echo $e->getMessage();
    echo PHP_EOL;
    echo $e->getPrevious()->getMessage();
} // will output:
// thrown from finally
// thrown from catch
?>

The same happens even if explicitly pass null as previous exception:
<?php
try {
    try {
        throw new Exception('thrown from try');
    } finally {
        throw new Exception('thrown from finally', null, null);
    }
} catch(Exception $e) {
    echo $e->getMessage();
    echo PHP_EOL;
    echo $e->getPrevious()->getMessage();
} // will output:
// thrown from finally
// thrown from try
?>

Also it is possible to pass previous exception explicitly, the 'original' one will be still appended to the chain, e.g.:
<?php
try {
    try {
        throw new Exception('thrown from try');
    } finally {
        throw new Exception(
            'thrown from finally',
            null,
            new Exception('Explicitly set previous!')
        );
    }
} catch(Exception $e) {
    echo $e->getMessage();
    echo PHP_EOL;
    echo $e->getPrevious()->getMessage();
    echo PHP_EOL;
    echo $e->getPrevious()->getPrevious()->getMessage();
} // will output:
// thrown from finally
// Explicitly set previous!
// thrown from try
?>

This seems to be true for versions 5.6-8.2.


Daan

1 year ago


I would like to emphasise that you can not rethrow an Exception inside a catch-block and expect that the next catch-block will handle it.

<?php try {
    throw new RuntimeException('error');           
} catch (RuntimeException $e) {
    throw $e;
} catch (Exception $e) {
    // this will not be executed[
}
?>


Источник

Хотя PHP уже давно поддерживает обработку исключений, однако, по сравнению с Java эта поддержка была довольно слабой

Первоначальная поддержка обработки исключений была введена в язык с 5 версии PHP, с двумя простыми встроенными классами исключений — Exception и ErrorException, с поддержкой дополнительных классов через SPL. Идея этого поста состоит в том, чтобы представить читателям современные возможности обработки исключений PHP. 

Новый интерфейс

Хотя PHP 7 предоставляет классы Error и Exception, давайте сначала затронем интерфейс Throwable . И Error и Exception классы реализуют Throwable интерфейс — это основа для любого объекта , который может быть брошен с помощью оператора throw. Единственное, что он не может быть реализован непосредственно в классах пользовательского пространства, только через расширение класса Exception. Кроме того, он обеспечивает единую точку для отлова обоих типов ошибок в одном выражении:

<?php


try {

// ваш код

} catch (Throwable $e) {

   echo 'Очень хороший способ отловить исключения и ошибки';

}

Список доступных встроенных классов исключений начиная с PHP 7.4:

  • Exception
  • ErrorException
  • Error
  • ArgumentCountError
  • ArithmeticError
  • AssertionError
  • DivisionByZeroError
  • CompileError
  • ParseError
  • TypeError

Дополнительные классы исключений можно найти в стандартной библиотеке PHP . И наиболее заметным из расширений JSON является класс JsonException.

THROWABLE

Интерфейс Throwable  PHP 7:

interface Throwable

{

    public function getMessage(): string;       // Error reason

    public function getCode(): int;             // Error code

    public function getFile(): string;          // Error begin file

    public function getLine(): int;             // Error begin line

    public function getTrace(): array;          // Return stack trace as array like debug_backtrace()

    public function getTraceAsString(): string; // Return stack trace as string

    public function getPrevious(): Throwable;   // Return previous `Trowable`

    public function __toString(): string;       // Convert into string

}

Вот иерархия Throwable:

interface Throwable

  |- Error implements Throwable

      |- ArithmeticError extends Error

          |- DivisionByZeroError extends ArithmeticError

      |- AssertionError extends Error

      |- ParseError extends Error

      |- TypeError extends Error

          |- ArgumentCountError extends TypeError

  |- Exception implements Throwable

      |- ClosedGeneratorException extends Exception

      |- DOMException extends Exception

      |- ErrorException extends Exception

      |- IntlException extends Exception

      |- LogicException extends Exception

          |- BadFunctionCallException extends LogicException

              |- BadMethodCallException extends BadFunctionCallException

          |- DomainException extends LogicException

          |- InvalidArgumentException extends LogicException

          |- LengthException extends LogicException

          |- OutOfRangeException extends LogicException

      |- PharException extends Exception

      |- ReflectionException extends Exception

      |- RuntimeException extends Exception

          |- OutOfBoundsException extends RuntimeException

          |- OverflowException extends RuntimeException

          |- PDOException extends RuntimeException

          |- RangeException extends RuntimeException

          |- UnderflowException extends RuntimeException

          |- UnexpectedValueException extends RuntimeException

Ошибка, почему?

В предыдущих версиях PHP ошибки обрабатывались совершенно иначе, чем исключения. Если возникала ошибка, то пока она не была фатальной, она могла быть обработана пользовательской функцией.

Проблема заключалась в том, что было несколько фатальных ошибок, которые не могли быть обработаны определяемым пользователем обработчиком ошибок. Это означало, что вы не могли корректно обрабатывать фатальные ошибки в PHP. Было несколько побочных эффектов, которые были проблематичными, такие как потеря контекста времени выполнения, деструкторы не вызывались, да и вообще иметь дело с ними было неудобно. В PHP 7 фатальные ошибки теперь являются исключениями, и мы можем легко их обработать. Фатальные ошибки приводят к возникновению исключений. Вам необходимо обрабатывать нефатальные ошибки с помощью функции обработки ошибок.

Вот пример ловли фатальной ошибки в PHP 7.1. Обратите внимание, что нефатальная ошибка не обнаружена.

<?php 


try {

   // будет генерировать уведомление, которое не будет поймано

   echo $someNotSetVariable;

   // фатальная ошибка, которая сейчас на самом деле ловится

   someNoneExistentFunction();

} catch (Error $e) {

      echo "Error caught: " . $e->getMessage();

}

Этот скрипт выведет сообщение об ошибке при попытке доступа к недопустимой переменной. Попытка вызвать функцию, которая не существует, приведет к фатальной ошибке в более ранних версиях PHP, но в PHP 7.1 вы можете ее перехватить. Вот вывод для скрипта:

Notice: Undefined variable: someNotSetVariable on line 3

Error caught: Call to undefined function someNoneExistentFunction()

Константы ошибок

В PHP много констант, которые используются в отношении ошибок. Эти константы используются при настройке PHP для скрытия или отображения ошибок определенных классов.

Вот некоторые из наиболее часто встречающихся кодов ошибок:

  • E_DEPRECATED — интерпретатор сгенерирует этот тип предупреждений, если вы используете устаревшую языковую функцию. Сценарий обязательно продолжит работать без ошибок.
  • E_STRICT — аналогично E_DEPRECATED, — указывает на то, что вы используете языковую функцию, которая не является стандартной в настоящее время и может не работать в будущем. Сценарий будет продолжать работать без каких-либо ошибок.
  • E_PARSE — ваш синтаксис не может быть проанализирован, поэтому ваш скрипт не запустится. Выполнение скрипта даже не запустится.
  • E_NOTICE — движок просто выведет информационное сообщение. Выполнение скрипта не прервется, и ни одна из ошибок не будет выдана.
  • E_ERROR — скрипт не может продолжить работу, и завершится. Выдает ошибки, а как они будут обрабатываться, зависит от обработчика ошибок.
  • E_RECOVERABLE_ERROR — указывает на то, что, возможно, произошла опасная ошибка, и движок работает в нестабильном состоянии. Дальнейшее выполнение зависит от обработчика ошибок, и ошибка обязательно будет выдана.

Полный список констант можно найти в руководстве по PHP.

Функция обработчика ошибок

Функция set_error_handler() используется, чтобы сообщить PHP как обрабатывать стандартные ошибки, которые не являются экземплярами класса исключений Error. Вы не можете использовать функцию обработчика ошибок для фатальных ошибок. Исключения ошибок должны обрабатываться с помощью операторов try/catch. set_error_handler() принимает callback функцию в качестве своего параметра. Callback-функции в PHP могут быть заданы двумя способами: либо строкой, обозначающей имя функции, либо передачей массива, который содержит объект и имя метода (именно в этом порядке). Вы можете указать защищенные и приватные методы для callable в объекте. Вы также можете передать значение null, чтобы указать PHP вернуться к использованию стандартного механизма обработки ошибок. Если ваш обработчик ошибок не завершает программу и возвращает результат, ваш сценарий будет продолжать выполняться со строки, следующей за той, где произошла ошибка.

PHP передает параметры в вашу функцию обработчика ошибок. Вы можете опционально объявить их в сигнатуре функции, если хотите использовать их в своей функции.

Вот пример:

<?php


function myCustomErrorHandler(int $errNo, string $errMsg, string $file, int $line) {

echo "Ух ты, мой обработчик ошибок получил #[$errNo] в [$file] на [$line]: [$errMsg]";

}


set_error_handler('myCustomErrorHandler');


try {

   why;

} catch (Throwable $e) {

   echo 'И моя ошибка: ' . $e->getMessage();

}

Если вы запустите этот код в PHP-консоли php -a, вы должны получить похожий вывод:

Error #[2] occurred in [php shell code] at line [3]: [Use of undefined constant why - assumed 'why' (this will throw an Error in a future version of PHP)]

Самые известные PHP библиотеки , которые делают обширное использование РНР set_error_handler() и могут сделать хорошие представления исключений и ошибок являются whoops,  и Symony Debug, ErrorHandler компоненты. Я смело рекомендую использовать один из них. Если не собираетесь их использовать в своем проекте, то вы всегда можете черпать вдохновение из их кода. В то время как компонент Debug широко используется в экосистеме Symfony, Whoops остается библиотекой выбора для фреймворка Laravel . 

Для подробного и расширенного использования, пожалуйста, обратитесь к руководству по PHP для обработчика ошибок.

Отображение или подавление нефатальной ошибки

Когда ваше приложение выходит в продакшн, логично, что вы хотите скрыть все системные сообщения об ошибках во время работы, и ваш код должен работать без генерации предупреждений или сообщений. Если вы собираетесь показать сообщение об ошибке, убедитесь, что оно сгенерировано и не содержит информации, которая может помочь злоумышленнику проникнуть в вашу систему.

В вашей среде разработки вы хотите, чтобы все ошибки отображались, чтобы вы могли исправить все проблемы, с которыми они связаны, но в процессе работы вы хотите подавить любые системные сообщения, отправляемые пользователю.

Для этого вам нужно настроить PHP, используя следующие параметры в вашем файле php.ini:

  • display_errors – может быть установлен в false для подавления сообщений
  • log_errors – может использоваться для хранения сообщений об ошибках в файлах журнала
  • error_reporting – можно настроить, какие ошибки вызывают отчет

Лучше всего корректно обрабатывать ошибки в вашем приложении. В производственном процессе вы должны скорее регистрировать необработанные ошибки, чем разрешать их отображение пользователю. Функция error_log() может использоваться для отправки сообщения одной из определенных процедур обработки ошибок. Вы также можете использовать функцию error_log() для отправки электронных писем, но лично вы бы предпочли использовать хорошее решение для регистрации ошибок и получения уведомлений при возникновении ошибок, например Sentry или Rollbar .

Существует вещь, называемая оператором контроля ошибок ( @ ), который по своей сути может игнорировать и подавлять ошибки. Использование очень простое — просто добавьте любое выражение PHP с символом «собаки», и сгенерированная ошибка будет проигнорирована. Хотя использование этого оператора может показаться интересным, я призываю вас не делать этого. Мне нравится называть это живым пережитком прошлого.

Больше информации для всех функций, связанных с ошибками PHP, можно найти в руководстве.

Исключения (Exceptions)

Исключения являются основной частью объектно-ориентированного программирования и впервые были представлены в PHP 5.0. Исключением является состояние программы, которое требует специальной обработки, поскольку оно не выполняется ожидаемым образом. Вы можете использовать исключение, чтобы изменить поток вашей программы, например, чтобы прекратить что-либо делать, если некоторые предварительные условия не выполняются.

Исключение будет возникать в стеке вызовов, если вы его не перехватите. Давайте посмотрим на простой пример:

try {

   print "это наш блок попыток n";

   throw new Exception();

} catch (Exception $e) {

   print "что-то пошло не так, есть улов!";

} finally {

   print "эта часть всегда выполняется";

}

PHP включает в себя несколько стандартных типов исключений, а стандартная библиотека PHP (SPL) включает в себя еще несколько. Хотя вам не нужно использовать эти исключения, это означает, что вы можете использовать более детальное обнаружение ошибок и отчеты. Классы Exception и Error реализуют интерфейс Throwable и, как и любые другие классы, могут быть расширены. Это позволяет вам создавать гибкие иерархии ошибок и адаптировать обработку исключений. Только класс, который реализует класс Throwable, может использоваться с ключевым словом throw. Другими словами, вы не можете объявить свой собственный базовый класс и затем выбросить его как исключение.

Надежный код может встретить ошибку и справиться с ней. Разумная обработка исключений повышает безопасность вашего приложения и облегчает ведение журнала и отладку. Управление ошибками в вашем приложении также позволит вам предложить своим пользователям лучший опыт. В этом разделе мы рассмотрим, как отлавливать и обрабатывать ошибки, возникающие в вашем коде.

Ловля исключений

Вы должны использовать try/catch структуру:

<?php


class MyCustomException extends Exception { }


function throwMyCustomException() {

      throw new MyCustomException('Здесь что-то не так.');

}


try {

   throwMyCustomException();

} catch (MyCustomException $e) {

   echo "Ваше пользовательское исключение поймано";

   echo $e->getMessage();

} catch (Exception $e) {

   echo "Стандартное исключение PHP";

}

Как видите, есть два предложения catch. Исключения будут сопоставляться с предложениями сверху вниз, пока тип исключения не будет соответствовать предложению catch. Эта очень простая функция throwMyCustomException() генерирует исключение MyCustomException, и мы ожидаем, что оно будет перехвачено в первом блоке. Любые другие исключения, которые произойдут, будут перехвачены вторым блоком. Здесь мы вызываем метод getMessage() из базового класса Exception. Вы можете найти больше информации о дополнительном методе в Exception PHP docs.

Кроме того, можно указать несколько исключений, разделяя их трубой ( | ).

Давайте посмотрим на другой пример:

<?php


class MyCustomException extends Exception { }

class MyAnotherCustomException extends Exception { }


try {

   throw new MyAnotherCustomException;

} catch (MyCustomException | MyAnotherCustomException $e) {

   echo "Caught : " . get_class($e);

}

Этот очень простой блок catch будет перехватывать исключения типа MyCustomException и MyAnotherCustomException.

Немного более продвинутый сценарий:

// exceptions.php

use SymfonyComponentHttpKernelExceptionNotFoundHttpException;


try {

   throw new NotFoundHttpException();

} catch (Exception $e) { 

   echo 1;

} catch (NotFoundHttpException $e) { 

   echo 2;

} catch (Exception $e) { 

   echo 3;

} finally { 

   echo 4;

}

Это ваш окончательный ответ?

В PHP 5.5 и более поздних, блок finally также может быть указан после или вместо блоков catch. Код внутри блока finally всегда будет выполняться после блоков try и catch независимо от того, было ли выброшено исключение, и до возобновления нормального выполнения. Одним из распространенных применений блока finally является закрытие соединения с базой данных, но, наконец, его можно использовать везде, где вы хотите, чтобы код всегда выполнялся.

<?php


class MyCustomException extends Exception { }


function throwMyCustomException() {

   throw new MyCustomException('Здесь что-то не так');

}


try {

   throwMyCustomException();

} catch (MyCustomException $e) {

   echo "Ваше пользовательское исключение поймано ";

   echo $e->getMessage();

} catch (Exception $e) {

   echo "Стандартное исключение PHP";
} finally {

  echo "Я всегда тут";

}

Вот хороший пример того, как работают операторы PHP catch/finally:

<?php


try {

   try {

      echo 'a-';

      throw new exception();

      echo 'b-';

   } catch (Exception $e) {

      echo 'пойманный-';

      throw $e;

   } finally {

      echo 'завершенный-';

   }

} catch (Exception $e) {

   echo 'конец-';

}

Функция обработчика исключений

Любое исключение, которое не было обнаружено, приводит к фатальной ошибке. Если вы хотите изящно реагировать на исключения, которые не перехватываются в блоках перехвата, вам нужно установить функцию в качестве обработчика исключений по умолчанию.

Для этого вы используете функцию set_exception_handler() , которая принимает вызываемый элемент в качестве параметра. Ваш сценарий завершится после того, как вызов будет выполнен.

Функция restore_exception_handler() вернет обработчик исключений к его предыдущему значению.

<?php


class MyCustomException extends Exception { }


function exception_handler($exception) {

   echo "Uncaught exception: " , $exception->getMessage(), "n";

}


set_exception_handler('exception_handler');


try {

   throw new Exception('Uncaught Exception');

} catch (MyCustomException $e) {

   echo "Ваше пользовательское исключение поймано ";

   echo $e->getMessage();

} finally {

   echo "Я всегда тут";

}


print "Не выполнено";

Здесь простая функция exception_handler будет выполняться после блока finally, когда ни один из типов исключений не был сопоставлен. Последний вывод никогда не будет выполнен.

Для получения дополнительной информации обратитесь к документации PHP. 

Старый добрый «T_PAAMAYIM_NEKUDOTAYIM»

Вероятно, это было самое известное сообщение об ошибке PHP. В последние годы было много споров по этому поводу. Вы можете прочитать больше в отличном сообщении в блоге от Фила Осетра .  

Сегодня я с гордостью могу сказать, что если вы запустите этот код с PHP 7, то сообщение о T_PAAMAYIM_NEKUDOTAYIM больше не будет:

<?php


class foo

{

   static $bar = 'baz';

}


var_dump('foo'::$bar);


// Output PHP < 7.0:

// PHP Parse error: syntax error, unexpected '::' (T_PAAMAYIM_NEKUDOTAYIM) in php shell code on line 1

// Output PHP > 7.0:

// string(3) "baz"

?>

В заключении

Со времени первого внедрения обработки исключений в PHP прошло много лет, пока мы не получили гораздо более надежную и зрелую обработку исключений, чем в Java. Обработка ошибок в PHP 7 получила много внимания, что делает его хорошим, открывая пространство для будущих улучшений, если мы действительно с сегодняшней точки зрения нуждаемся в них.

Источник

Время на прочтение
7 мин

Количество просмотров 31K

Что я понимаю под правильной обработкой:

  • Универсальное решение, которое можно вставить в любой существующий код;
  • Легко расширяемое решение;
  • В PHP аж три «механизма ошибок»: собственно ошибки (error), исключения (exception) и утверждения (assertion). Свести три механизма к одному — exception. В комментариях к предыдущей статье на эту тему выражалось мнение, что exception это плохой и/или сложный метод обработки ошибок. Я так не считаю и готов это обсудить в комментариях;
  • Опциональное логирование;
  • Общий обработчик exception, который будет поддерживать разные форматы вывода и debug/production режимы;
  • В debug режиме должен выводится trace. Требования к trace: компактный, понятный и по возможности ссылки на открытие файлов в IDE.

Универсальное решение

Для этого сделаем класс exceptionHandlerClass. В exceptionHandlerClass будут храниться настройки и статические методы — обработчики error, exception и assertion. Еще нам нужны методы setupHandlers и restoreHandlers. Первый метод настроит перехват ошибок. Error и assertion обработчики будут бросать ErrorException. Exception обработчик будет обрабатывать необработанные Exception и в зависимости от настроек выводить соответствующий ответ. restoreHandlers вернет все обработчики в изначальное состояние — это поможет при встраивании класса в код с существующим механизмом обработки ошибок. Подключение выглядит так:

  1. require ‘exceptionHandler/exceptionHandlerClass.php’;
  2. exceptionHandlerClass::setupHandlers();

включение debug режима (по умолчанию выключен) :

  1. exceptionHandlerClass::$debug = true;

Форматы вывода

Проще объяснить на примере: для вывода trace на веб странице я оберну его в таги pre и применю htmlspecialchars(), с другой стороны этот же trace при выводе в консоль будет не удобно читать, было бы проще, если бы это был plainText. Если нужно вывести ошибку как ответ SоapServer, то это должен быть правильно сформированный XML документ (SoapFault). Если скрипт выводит бинарные данные, например изображение, то удобней выводить ошибки через WildFire. Во всех этих ситуация нужно просто применить разные форматы вывода.
Для разных форматов будем создавать разные классы. Я для начала реализую два формата вывода exceptionHandlerOutputWeb(для веба) и exceptionHandlerOutputCli(для командной строки). Так же нам понадобиться класс фабрика (exceptionHandlerOutputFactory), в котором будет инкапсулирована логика, когда какой формат вывода применить.

  1. public function getExceptionHandlerOutput(){
  2.     if(php_sapi_name() == ‘cli’){
  3.         return new exceptionHandlerOutputCli();
  4.     }
  5.     return new exceptionHandlerOutputWeb();
  6. }

При вызове setupHandlers можно установить формат вывода, передав экземпляр класса exceptionHandlerOutput* или exceptionHandlerOutputFactory*.

  1. exceptionHandlerClass::setupHandlers(new exceptionHandlerOutputAjax());

Благодаря такой архитектуре можно легко расширять форматы. Для создания нового формата достаточно создать класс, который будет наследоваться от абстрактного класса exceptionHandlerOutput и реализовать один метод (output).

  1. class exceptionHandlerOutputAjax extends exceptionHandlerOutput{
  2.     public function output($exception, $debug){
  3.         header(‘HTTP/1.0 500 Internal Server Error’, true, 500);
  4.         header(‘Status: 500 Internal Server Error’, true, 500);
  5.         $response = array(
  6.             ‘error’ => true,
  7.             ‘message’ => »,
  8.         );
  9.         if($debug){
  10.             $response[‘message’] = $exception->getMessage();
  11.         } else {
  12.             $response[‘message’] = self::$productionMessage;
  13.         }
  14.         exit(json_encode($response));
  15.     }
  16. }

Если нужна более сложная логика для автоматического выбора формата вывода, нужно создать класс, наследуемый от exceptionHandlerOutputFactory и реализовать метод getExceptionHandlerOutput.

  1. class exceptionHandlerOutputAjaxFactory extends exceptionHandlerOutputDefaultFactory{
  2.     public function getExceptionHandlerOutput() {
  3.         if( self::detect() ){
  4.             return new exceptionHandlerOutputAjax();
  5.         }
  6.         parent::getExceptionHandlerOutput();
  7.     }
  8.     public static function detect(){
  9.         return (!empty($_SERVER[‘HTTP_X_REQUESTED_WITH’]) 
  10.             && strtolower($_SERVER[‘HTTP_X_REQUESTED_WITH’]) == ‘xmlhttprequest’);
  11.     }
  12. }
  13. exceptionHandlerClass::setupHandlers(new exceptionHandlerOutputAjaxFactory());

Логирование

Как я и сказал выше логирование можно включать по желанию. Для этого в exceptionHandlerClass создан метод exceptionLog

  1. public static function exceptionLog($exception, $logPriority = null){
  2.     if(!is_null(self::$exceptionHandlerLog)){
  3.         self::$exceptionHandlerLog->log($exception, $logPriority);
  4.     }
  5. }

если нужно включить логирование, то достаточно сделать следующее:

  1. exceptionHandlerClass::$exceptionHandlerLog = new exceptionHandlerSimpleLog();

Класс для логирования должен наследоваться от абстрактного exceptionHandlerLog и реализовывать метод log

  1. class exceptionHandlerSimpleLog extends exceptionHandlerLog{
  2.     public function log($exception, $logType){
  3.         switch ($logType){
  4.             case self::uncaughtException:
  5.                 error_log($exception->getMessage());
  6.                 break;
  7.         }
  8.     }
  9. }

logType это одна из констант объявленных exceptionHandlerLog

  1. const uncaughtException = 0; //необработанные исключения
  2. const caughtException = 1; //вызов метода логирования вне обработчиков ошибок
  3. const ignoredError = 2; //ошибки маскированные @, логируются если выключена опция scream
  4. const lowPriorityError = 3; //ошибки которые не превращаются exception
  5. const assertion = 4; //assertion 

Имея logType и exception разработчик может сам решить какие искллючения и как логировать. Например, uncaughtException можно высылать по почте, ignoredError с severity E_ERROR логировать в файл итп.

Trace

При выводе trace я хочу видеть тип исключения, сообщение и собственно сам trace. В trace для каждого вызова должно выводится, какая функция вызвалась, список «кратких» параметров, файл и строка где произошел вызов. Что такое «краткие» параметры объясню на примерах: если функцию вызвали со строкой длиной в 1000 символов, то наличие этой строки в trace ничем не поможет при решении проблемы, а только затруднит чтение trace, это же касается массивов с большой вложенностью. Вывод trace на экран просто должен подсказать, где искать. Чтобы разобраться, что именно происходит нужно дебажить с помощью xdebug или примитивных var_dump() и die(), кому как больше нравится.
Пример trace:

	[ErrorException]: E_WARNING - mysql_connect(): Can't connect to MySQL server on 'localhost' (10061)
	#0: mysql_connect()
	    D:projects1dindex.php:19
	#1: testClass::test1("длиная строка…eeeeeery long string"(56))
	    D:projects1dindex.php:22
	#2: testClass->test2(testClass(), -∞, i:iTest, c:testClass, fa:testClass::test2)
	    D:projects1dindex.php:27
	#3: testAll(r:stream, fs:testClass::test1)
	    D:projects1dindex.php:30

Легенда

  • r: — resource
  • fs: — function (callable string)
  • fa: — function (callable array)
  • i: — interface (string)
  • c: — class (string)
  • ∞/INF — infinity
  • testClass() — object of type testClass
  • «»(n) — string, в скобках указана длина, … — место где вырезана часть строки
  • array(n) — array, в скобках указана длина

И самое полезное… ссылки на открытие файлов в IDE прямо из trace.

При нажатии на ссылку в IDE откроется соответствующий файл на соответствующей строке.
Для консольного режима (консоль NetBeans):
NetBeans Console

  1. exceptionHandlerOutputCli::setFileLinkFormat(‘: in %f on line %l’);

Для веб режима (TextMate):

  1. exceptionHandlerOutputWeb::setFileLinkFormat(‘txmt://open/?file://%f&line=%l’);

Можно реализовать для NetbBeans (или другого IDE). Для этого нужно: зарегистрировать протокол; сделать обработчик этого протокола (самое простое — bat файл). В обработчике через командную строку вызвать NetBeans с соответствующим файлом и строкой. Но это тема для следующей статьи.
Код писался за два дня так, что возможны мелкие недочеты. Скачать (не было времени, чтобы выложить в репозиторий).

UPD: перенесено в блог PHP
UPD2: в продолжение темы работа с исключениями в PHP

Источник

Антон Шевчук // Web-разработчик

Не совершает ошибок только тот, кто ничего не делает, и мы тому пример – трудимся не покладая рук над созданием рабочих мест для тестировщиков :)

О да, в этой статье я поведу свой рассказа об ошибках в PHP, и том как их обуздать.

Ошибки

Разновидности в семействе ошибок

Перед тем как приручать ошибки, я бы рекомендовал изучить каждый вид и отдельно обратить внимание на самых ярких представителей.

Чтобы ни одна ошибка не ушла незамеченной потребуется включить отслеживание всех ошибок с помощью функции error_reporting(), а с помощью директивы display_errors включить их отображение:

<?php
error_reporting(E_ALL);
ini_set('display_errors', 1);

Фатальные ошибки

Самый грозный вид ошибок – фатальные, они могут возникнуть как при компиляции, так и при работе парсера или PHP-скрипта, выполнение скрипта при этом прерывается.

E_PARSE
Это ошибка появляется, когда вы допускаете грубую ошибку синтаксиса и интерпретатор PHP не понимает, что вы от него хотите, например если не закрыли фигурную или круглую скобочку:

<?php
/**
 Parse error: syntax error, unexpected end of file
 */
{

Или написали на непонятном языке:

<?php
/**
 Parse error: syntax error, unexpected '...' (T_STRING)
 */
Тут будет ошибка парсера

Лишние скобочки тоже встречаются, и не важно круглые либо фигурные:

<?php
/**
 Parse error: syntax error, unexpected '}'
 */
}

Отмечу один важный момент – код файла, в котором вы допустили parse error не будет выполнен, следовательно, если вы попытаетесь включить отображение ошибок в том же файле, где возникла ошибка парсера то это не сработает:

<?php
// этот код не сработает
error_reporting(E_ALL);
ini_set('display_errors', 1);

// т.к. вот тут
ошибка парсера

E_ERROR
Это ошибка появляется, когда PHP понял что вы хотите, но сделать сие не получилось ввиду ряда причин, так же прерывает выполнение скрипта, при этом код до появления ошибки сработает:

Не был найден подключаемый файл:

/**
 Fatal error: require_once(): Failed opening required 'not-exists.php' (include_path='.:/usr/share/php:/usr/share/pear')
 */
require_once 'not-exists.php';

Было брошено исключение (что это за зверь, расскажу немного погодя), но не было обработано:

/**
 Fatal error: Uncaught exception 'Exception'
 */
throw new Exception();

При попытке вызвать несуществующий метод класса:

/**
 Fatal error: Call to undefined method stdClass::notExists()
 */
$stdClass = new stdClass();
$stdClass->notExists();

Отсутствия свободной памяти (больше, чем прописано в директиве memory_limit) или ещё чего-нить подобного:

/**
 Fatal Error: Allowed Memory Size
 */
$arr = array();

while (true) {
    $arr[] = str_pad(' ', 1024);
}

Очень часто происходит при чтении либо загрузки больших файлов, так что будьте внимательны с вопросом потребляемой памяти

Рекурсивный вызов функции. В данном примере он закончился на 256-ой итерации, ибо так прописано в настройках xdebug:

/**
 Fatal error: Maximum function nesting level of '256' reached, aborting!
 */
function deep() {
    deep();
}
deep();

Не фатальные

Данный вид не прерывает выполнение скрипта, но именно их обычно находит тестировщик, и именно они доставляют больше всего хлопот у начинающих разработчиков.

E_WARNING
Частенько встречается, когда подключаешь файл с использованием include, а его не оказывается на сервере или ошиблись указывая путь к файлу:

/**
 Warning: include_once(): Failed opening 'not-exists.php' for inclusion
 */
include_once 'not-exists.php';

Бывает, если используешь неправильный тип аргументов при вызове функций:

/**
 Warning: join(): Invalid arguments passed
 */
join('string', 'string');

Их очень много, и перечислять все не имеет смысла…

E_NOTICE
Это самые распространенные ошибки, мало того, есть любители отключать вывод ошибок и клепают их целыми днями. Возникают при целом ряде тривиальных ошибок.

Когда обращаются к неопределенной переменной:

/**
 Notice: Undefined variable: a
 */
echo $a;

Когда обращаются к несуществующему элементу массива:

<?php
/**
 Notice: Undefined index: a
 */
$b = array();
$b['a'];

Когда обращаются к несуществующей константе:

/**
 Notice: Use of undefined constant UNKNOWN_CONSTANT - assumed 'UNKNOWN_CONSTANT'
 */
echo UNKNOWN_CONSTANT;

Когда не конвертируют типы данных:

/**
 Notice: Array to string conversion
 */
echo array();

Для избежания подобных ошибок – будьте внимательней, и если вам IDE подсказывает о чём-то – не игнорируйте её:

PHP E_NOTICE in PHPStorm

E_STRICT
Это ошибки, которые научат вас писать код правильно, чтобы не было стыдно, тем более IDE вам эти ошибки сразу показывают. Вот например, если вызвали не статический метод как статику, то код будет работать, но это как-то неправильно, и возможно появление серьёзных ошибок, если в дальнейшем метод класса будет изменён, и появится обращение к $this:

/**
 Strict standards: Non-static method Strict::test() should not be called statically
 */
class Strict { 
    public function test() { 
        echo 'Test'; 
    } 
}

Strict::test();

E_DEPRECATED
Так PHP будет ругаться, если вы используете устаревшие функции (т.е. те, что помечены как deprecated, и в следующем мажорном релизе их не будет):

/**
 Deprecated: Function split() is deprecated
 */

// популярная функция, всё никак не удалят из PHP
// deprecated since 5.3
split(',', 'a,b');

В моём редакторе подобные функции будут зачёркнуты:

PHP E_DEPRECATED in PHPStorm

Обрабатываемые

Этот вид, которые разводит сам разработчик кода, я их уже давно не встречал, не рекомендую их вам заводить:

  • E_USER_ERROR – критическая ошибка
  • E_USER_WARNING – не критическая ошибка
  • E_USER_NOTICE – сообщения которые не являются ошибками

Отдельно стоит отметить E_USER_DEPRECATED – этот вид всё ещё используется очень часто для того, чтобы напомнить программисту, что метод или функция устарели и пора переписать код без использования оной. Для создания этой и подобных ошибок используется функция trigger_error():

/**
 * @deprecated Deprecated since version 1.2, to be removed in 2.0
 */
function generateToken() {
    trigger_error('Function `generateToken` is deprecated, use class `Token` instead', E_USER_DEPRECATED);
    // ...
    // code ...
    // ...
}

Теперь, когда вы познакомились с большинством видов и типов ошибок, пора озвучить небольшое пояснение по работе директивы display_errors:

  • если display_errors = on, то в случае ошибки браузер получит html c текстом ошибки и кодом 200
  • если же display_errors = off, то для фатальных ошибок код ответа будет 500 и результат не будет возвращён пользователю, для остальных ошибок – код будет работать неправильно, но никому об этом не расскажет

Приручение

Для работы с ошибками в PHP существует 3 функции:

  • set_error_handler() — устанавливает обработчик для ошибок, которые не обрывают работу скрипта (т.е. для не фатальных ошибок)
  • error_get_last() — получает информацию о последней ошибке
  • register_shutdown_function() — регистрирует обработчик который будет запущен при завершении работы скрипта. Данная функция не относится непосредственно к обработчикам ошибок, но зачастую используется именно для этого

Теперь немного подробностей об обработке ошибок с использованием set_error_handler(), в качестве аргументов данная функция принимает имя функции, на которую будет возложена миссия по обработке ошибок и типы ошибок которые будут отслеживаться. Обработчиком ошибок может так же быть методом класса, или анонимной функцией, главное, чтобы он принимал следующий список аргументов:

  • $errno – первый аргумент содержит тип ошибки в виде целого числа
  • $errstr – второй аргумент содержит сообщение об ошибке
  • $errfile – необязательный третий аргумент содержит имя файла, в котором произошла ошибка
  • $errline – необязательный четвертый аргумент содержит номер строки, в которой произошла ошибка
  • $errcontext – необязательный пятый аргумент содержит массив всех переменных, существующих в области видимости, где произошла ошибка

В случае если обработчик вернул true, то ошибка будет считаться обработанной и выполнение скрипта продолжится, иначе — будет вызван стандартный обработчик, который логирует ошибку и в зависимости от её типа продолжит выполнение скрипта или завершит его. Вот пример обработчика:

<?php
    // включаем отображение всех ошибок, кроме E_NOTICE
    error_reporting(E_ALL & ~E_NOTICE);
    ini_set('display_errors', 1);
    
    // наш обработчик ошибок
    function myHandler($level, $message, $file, $line, $context) {
        // в зависимости от типа ошибки формируем заголовок сообщения
        switch ($level) {
            case E_WARNING:
                $type = 'Warning';
                break;
            case E_NOTICE:
                $type = 'Notice';
                break;
            default;
                // это не E_WARNING и не E_NOTICE
                // значит мы прекращаем обработку ошибки
                // далее обработка ложится на сам PHP
                return false;
        }
        // выводим текст ошибки
        echo "<h2>$type: $message</h2>";
        echo "<p><strong>File</strong>: $file:$line</p>";
        echo "<p><strong>Context</strong>: $". join(', $', array_keys($context))."</p>";
        // сообщаем, что мы обработали ошибку, и дальнейшая обработка не требуется
        return true;
    }
    
    // регистрируем наш обработчик, он будет срабатывать на для всех типов ошибок
    set_error_handler('myHandler', E_ALL);

У вас не получится назначить более одной функции для обработки ошибок, хотя очень бы хотелось регистрировать для каждого типа ошибок свой обработчик, но нет – пишите один обработчик, и всю логику отображения для каждого типа описывайте уже непосредственно в нём

С обработчиком, который написан выше есть одна существенная проблема – он не ловит фатальные ошибки, и вместо сайта пользователи увидят лишь пустую страницу, либо, что ещё хуже, сообщение об ошибке. Дабы не допустить подобного сценария следует воспользоваться функцией register_shutdown_function() и с её помощью зарегистрировать функцию, которая всегда будет выполняться по окончанию работы скрипта:

function shutdown() {
    echo 'Этот текст будет всегда отображаться';
}
register_shutdown_function('shutdown');

Данная функция будет срабатывать всегда!

Но вернёмся к ошибкам, для отслеживания появления в коде ошибки воспользуемся функцией error_get_last(), с её помощью можно получить информацию о последней выявленной ошибке, а поскольку фатальные ошибки прерывают выполнение кода, то они всегда будут выполнять роль “последних”:

function shutdown() {
    $error = error_get_last();
    if (
        // если в коде была допущена ошибка
        is_array($error) &&
        // и это одна из фатальных ошибок
        in_array($error['type'], [E_ERROR, E_PARSE, E_CORE_ERROR, E_COMPILE_ERROR])
    ) {
        // очищаем буфер вывода (о нём мы ещё поговорим в последующих статьях)
        while (ob_get_level()) {
            ob_end_clean();
        }
        // выводим описание проблемы
        echo 'Сервер находится на техническом обслуживании, зайдите позже';
    }
}
register_shutdown_function('shutdown');

Задание
Дополнить обработчик фатальных ошибок выводом исходного кода файла где была допущена ошибка, а так же добавьте подсветку синтаксиса выводимого кода.

О прожорливости

Проведём простой тест, и выясним – сколько драгоценных ресурсов кушает самая тривиальная ошибка:

/**
 * Этот код не вызывает ошибок
 */

// сохраняем параметры памяти и времени выполнения скрипта
$memory = memory_get_usage();
$time= microtime(true);

$a = '';
$arr = [];
for ($i = 0; $i < 10000; $i++) {
    $arr[$a] = $i;
}

printf('%f seconds <br/>', microtime(true) - $time);
echo number_format(memory_get_usage() - $memory, 0, '.', ' '), ' bytes<br/>';

В результате запуска данного скрипта у меня получился вот такой результат:

0.002867 seconds 
984 bytes

Теперь добавим ошибку в цикле:

/**
 * Этот код содержит ошибку
 */

// сохраняем параметры памяти и времени выполнения скрипта
$memory = memory_get_usage();
$time= microtime(true);

$a = '';
$arr = [];
for ($i = 0; $i < 10000; $i++) {
    $arr[$b] = $i; // тут ошиблись с именем переменной
}

printf('%f seconds <br/>', microtime(true) - $time);
echo number_format(memory_get_usage() - $memory, 0, '.', ' '), ' bytes<br/>';

Результат ожидаемо хуже, и на порядок (даже на два порядка!):

0.263645 seconds 
992 bytes

Вывод однозначен – ошибки в коде приводят к лишней прожорливости скриптов – так что во время разработки и тестирования приложения включайте отображение всех ошибок!

Тестирование проводил на PHP версии 5.6, в седьмой версии результат лучше – 0.0004 секунды против 0.0050 – разница только на один порядок, но в любом случае результат стоит прикладываемых усилий по исправлению ошибок

Где собака зарыта

В PHP есть спец символ «@» – оператор подавления ошибок, его используют дабы не писать обработку ошибок, а положится на корректное поведение PHP в случае чего:

<?php
    echo @UNKNOWN_CONSTANT;

При этом обработчик ошибок указанный в set_error_handler() всё равно будет вызван, а факт того, что к ошибке было применено подавление можно отследить вызвав функцию error_reporting() внутри обработчика, в этом случае она вернёт 0.

Если вы в такой способ подавляете ошибки, то это уменьшает нагрузку на процессор в сравнении с тем, если вы их просто скрываете (см. сравнительный тест выше), но в любом случае, подавление ошибок это зло

Исключения

В эру PHP4 не было исключений (exceptions), всё было намного сложнее, и разработчики боролись с ошибками как могли, это было сражение не на жизнь, а на смерть… Окунуться в эту увлекательную историю противостояния можете в статье Исключительный код. Часть 1. Стоит ли её читать сейчас? Думаю да, ведь это поможет вам понять эволюцию языка, и раскроет всю прелесть исключений

Исключения — исключительные событие в PHP, в отличии от ошибок не просто констатируют наличие проблемы, а требуют от программиста дополнительных действий по обработке каждого конкретного случая.

К примеру, скрипт должен сохранить какие-то данные в кеш файл, если что-то пошло не так (нет доступа на запись, нет места на диске), генерируется исключение соответствующего типа, а в обработчике исключений принимается решение – сохранить в другое место или сообщить пользователю о проблеме.

Исключение – это объект который наследуется от класса Exception, содержит текст ошибки, статус, а также может содержать ссылку на другое исключение которое стало первопричиной данного. Модель исключений в PHP схожа с используемыми в других языках программирования. Исключение можно инициировать (как говорят, “бросить”) при помощи оператора throw, и можно перехватить (“поймать”) оператором catch. Код генерирующий исключение, должен быть окружен блоком try, для того чтобы можно было перехватить исключение. Каждый блок try должен иметь как минимум один соответствующий ему блок catch или finally:

try {
    // код который может выбросить исключение
    if (rand(0, 1)) {
        throw new Exception('One')
    } else {
        echo 'Zero';
    }
} catch (Exception $e) {
    // код который может обработать исключение
    echo $e->getMessage();
}

В каких случаях стоит применять исключения:

  • если в рамках одного метода/функции происходит несколько операций которые могут завершиться неудачей
  • если используемый вами фреймверк или библиотека декларируют их использование

Для иллюстрации первого сценария возьмём уже озвученный пример функции для записи данных в файл – помешать нам может очень много факторов, а для того, чтобы сообщить выше стоящему коду в чем именно была проблема необходимо создать и выбросить исключение:

$directory = __DIR__ . DIRECTORY_SEPARATOR . 'logs';

// директории может не быть
if (!is_dir($directory)) {
    throw new Exception('Directory `logs` is not exists');
}

// может не быть прав на запись в директорию
if (!is_writable($directory)) {
    throw new Exception('Directory `logs` is not writable');
}

// возможно кто-то уже создал файл, и закрыл к нему доступ
if (!$file = @fopen($directory . DIRECTORY_SEPARATOR . date('Y-m-d') . '.log', 'a+')) {
    throw new Exception('System can't create log file');
}

fputs($file, date('[H:i:s]') . " donen");
fclose($file);

Соответственно ловить данные исключения будем примерно так:

try {
    // код который пишет в файл
    // ...
} catch (Exception $e) {
    // выводим текст ошибки
    echo 'Не получилось: '. $e->getMessage();
}

В данном примере приведен очень простой сценарий обработки исключений, когда у нас любая исключительная ситуация обрабатывается на один манер. Но зачастую – различные исключения требуют различного подхода к обработке, и тогда следует использовать коды исключений и задать иерархию исключений в приложении:

// исключения файловой системы
class FileSystemException extends Exception {}

// исключения связанные с директориями
class DirectoryException extends FileSystemException {
    // коды исключений
    const DIRECTORY_NOT_EXISTS =  1;
    const DIRECTORY_NOT_WRITABLE = 2;
}

// исключения связанные с файлами
class FileException extends FileSystemException {}

Теперь, если использовать эти исключения то можно получить следующий код:

try {
    // код который пишет в файл
    if (!is_dir($directory)) {
        throw new DirectoryException('Directory `logs` is not exists', DirectoryException::DIRECTORY_NOT_EXISTS);
    }

    if (!is_writable($directory)) {
        throw new DirectoryException('Directory `logs` is not writable', DirectoryException::DIRECTORY_NOT_WRITABLE);
    }

    if (!$file = @fopen($directory . DIRECTORY_SEPARATOR . date('Y-m-d') . '.log', 'a+')) {
        throw new FileException('System can't open log file');
    }

    fputs($file, date('[H:i:s]'') . " donen");
    fclose($file);
} catch (DirectoryException $e) {
    echo 'С директорией возникла проблема: '. $e->getMessage();
} catch (FileException $e) {
    echo 'С файлом возникла проблема: '. $e->getMessage();
} catch (FileSystemException $e) {
    echo 'Ошибка файловой системы: '. $e->getMessage();
} catch (Exception $e) {
    echo 'Ошибка сервера: '. $e->getMessage();
}

Важно помнить, что Exception — это прежде всего исключительное событие, иными словами исключение из правил. Не нужно использовать их для обработки очевидных ошибок, к примеру, для валидации введённых пользователем данных (хотя тут не всё так однозначно). При этом обработчик исключений должен быть написан в том месте, где он будет способен его обработать. К примеру, обработчик для исключений вызванных недоступностью файла для записи должен быть в методе, который отвечает за выбор файла или методе его вызывающем, для того что бы он имел возможность выбрать другой файл или другую директорию.

Так, а что будет если не поймать исключение? Вы получите “Fatal Error: Uncaught exception …”. Неприятно.
Чтобы избежать подобной ситуации следует использовать функцию set_exception_handler() и установить обработчик для исключений, которые брошены вне блока try-catch и не были обработаны. После вызова такого обработчика выполнение скрипта будет остановлено:

// в качестве обработчика событий 
// будем использовать анонимную функцию
set_exception_handler(function($exception) {
    /** @var Exception $exception */
    echo $exception->getMessage(), "<br/>n";
    echo $exception->getFile(), ':', $exception->getLine(), "<br/>n";
    echo $exception->getTraceAsString(), "<br/>n";
});

Ещё расскажу про конструкцию с использованием блока finally – этот блок будет выполнен вне зависимости от того, было выброшено исключение или нет:

try {
    // код который может выбросить исключение
} catch (Exception $e) {
    // код который может обработать исключение
    // если конечно оно появится
} finally {
    // код, который будет выполнен при любом раскладе
}

Для понимания того, что это нам даёт приведу следующий пример использования блока finally:

try {
    // где-то глубоко внутри кода
    // соединение с базой данных
    $handler = mysqli_connect('localhost', 'root', '', 'test');

    try {
        // при работе с БД возникла исключительная ситуация
        // ...
        throw new Exception('DB error');
    } catch (Exception $e) {
        // исключение поймали, обработали на своём уровне
        // и должны его пробросить вверх, для дальнейшей обработки
        throw new Exception('Catch exception', 0, $e);
    } finally {
        // но, соединение с БД необходимо закрыть
        // будем делать это в блоке finally
        mysqli_close($handler);
    }

    // этот код не будет выполнен, если произойдёт исключение в коде выше
    echo "Ok";
} catch (Exception $e) {
    // ловим исключение, и выводим текст
    echo $e->getMessage();
    echo "<br/>";
    // выводим информацию о первоначальном исключении
    echo $e->getPrevious()->getMessage();
}

Т.е. запомните – блок finally будет выполнен даже в том случае, если вы в блоке catch пробрасываете исключение выше (собственно именно так он и задумывался).

Для вводной статьи информации в самый раз, кто жаждет ещё подробностей, то вы их найдёте в статье Исключительный код ;)

Задание
Написать свой обработчик исключений, с выводом текста файла где произошла ошибка, и всё это с подсветкой синтаксиса, так же не забудьте вывести trace в читаемом виде. Для ориентира – посмотрите как это круто выглядит у whoops.

PHP7 – всё не так, как было раньше

Так, вот вы сейчас всю информацию выше усвоили и теперь я буду грузить вас нововведениями в PHP7, т.е. я буду рассказывать о том, с чем вы столкнётесь через год работы PHP разработчиком. Ранее я вам рассказывал и показывал на примерах какой костыль нужно соорудить, чтобы отлавливать критические ошибки, так вот – в PHP7 это решили исправить, но как обычно завязались на обратную совместимость кода, и получили хоть и универсальное решение, но оно далеко от идеала. А теперь по пунктам об изменениях:

  1. при возникновении фатальных ошибок типа E_ERROR или фатальных ошибок с возможностью обработки E_RECOVERABLE_ERROR PHP выбрасывает исключение
  2. эти исключения не наследуют класс Exception (помните я говорил об обратной совместимости, это всё ради неё)
  3. эти исключения наследуют класс Error
  4. оба класса Exception и Error реализуют интерфейс Throwable
  5. вы не можете реализовать интерфейс Throwable в своём коде

Интерфейс Throwable практически полностью повторяет нам Exception:

interface Throwable
{
    public function getMessage(): string;
    public function getCode(): int;
    public function getFile(): string;
    public function getLine(): int;
    public function getTrace(): array;
    public function getTraceAsString(): string;
    public function getPrevious(): Throwable;
    public function __toString(): string;
}

Сложно? Теперь на примерах, возьмём те, что были выше и слегка модернизируем:

try {
    // файл, который вызывает ошибку парсера
    include 'e_parse_include.php';
} catch (Error $e) {
    var_dump($e);
}

В результате ошибку поймаем и выведем:

object(ParseError)#1 (7) {
  ["message":protected] => string(48) "syntax error, unexpected 'будет' (T_STRING)"
  ["string":"Error":private] => string(0) ""
  ["code":protected] => int(0)
  ["file":protected] => string(49) "/www/education/error/e_parse_include.php"
  ["line":protected] => int(4)
  ["trace":"Error":private] => array(0) { }
  ["previous":"Error":private] => NULL
}

Как видите – поймали исключение ParseError, которое является наследником исключения Error, который реализует интерфейс Throwable, в доме который построил Джек. Ещё есть другие, но не буду мучать – для наглядности приведу иерархию исключений:

interface Throwable
  |- Exception implements Throwable
  |    |- ErrorException extends Exception
  |    |- ... extends Exception
  |    `- ... extends Exception
  `- Error implements Throwable
      |- TypeError extends Error
      |- ParseError extends Error
      |- ArithmeticError extends Error
      |  `- DivisionByZeroError extends ArithmeticError
      `- AssertionError extends Error

TypeError – для ошибок, когда тип аргументов функции не совпадает с передаваемым типом:

try {
    (function(int $one, int $two) {
        return;
    })('one', 'two');
} catch (TypeError $e) {
    echo $e->getMessage();
}

ArithmeticError – могут возникнуть при математических операциях, к примеру когда результат вычисления превышает лимит выделенный для целого числа:

try {
    1 << -1;
} catch (ArithmeticError $e) {
    echo $e->getMessage();
}

DivisionByZeroError – ошибка деления на ноль:

try {
    1 / 0;
} catch (ArithmeticError $e) {
    echo $e->getMessage();
}

AssertionError – редкий зверь, появляется когда условие заданное в assert() не выполняется:

ini_set('zend.assertions', 1);
ini_set('assert.exception', 1);

try {
    assert(1 === 0);
} catch (AssertionError $e) {
    echo $e->getMessage();
}

При настройках production-серверов, директивы zend.assertions и assert.exception отключают, и это правильно

Задание
Написать универсальный обработчик ошибок для PHP7, который будет отлавливать все возможные исключения.

При написании данного раздела были использованы материалы из статьи Throwable Exceptions and Errors in PHP 7

Отладка

Иногда для отладки кода нужно отследить что происходило с переменной или объектом на определённом этапе, для этих целей есть функция debug_backtrace() и debug_print_backtrace() которые вернут историю вызовов функций/методов в обратном порядке:

<?php
function example() {
    echo '<pre>';
    debug_print_backtrace();
    echo '</pre>';
}

class ExampleClass {
    public static function method () {
        example();
    }
}

ExampleClass::method();

В результате выполнения функции debug_print_backtrace() будет выведен список вызовов приведших нас к данной точке:

#0  example() called at [/www/education/error/backtrace.php:10]
#1  ExampleClass::method() called at [/www/education/error/backtrace.php:14]

Проверить код на наличие синтаксических ошибок можно с помощью функции php_check_syntax() или же команды php -l [путь к файлу], но я не встречал использования оных.

Assert

Отдельно хочу рассказать о таком экзотическом звере как assert() в PHP, собственно это кусочек контрактной методологии программирования, и дальше я расскажу вам как я никогда его не использовал :)

Первый случай – это когда вам надо написать TODO прямо в коде, да так, чтобы точно не забыть реализовать заданный функционал:

// включаем вывод ошибок
error_reporting(E_ALL);
ini_set('display_errors', 1);

// включаем asserts
ini_set('zend.assertions', 1);
ini_set('assert.active', 1);

assert(false, "Remove it!");

В результате выполнения данного кода получим E_WARNING:

Warning: assert(): Remove it! failed

PHP7 можно переключить в режим exception, и вместо ошибки будет всегда появляться исключение AssertionError:

// включаем asserts
ini_set('zend.assertions', 1);
ini_set('assert.active', 1);
// переключаем на исключения
ini_set('assert.exception', 1);

assert(false, "Remove it!");

В результате ожидаемо получаем не пойманный AssertionError. При необходимости, можно выбрасывать произвольное исключение:

assert(false, new Exception("Remove it!"));

Но я бы рекомендовал использовать метки @TODO, современные IDE отлично с ними работают, и вам не нужно будет прикладывать дополнительные усилия и ресурсы для работы с ними

Второй вариант использования – это создание некоего подобия TDD, но помните – это лишь подобие. Хотя, если сильно постараться, то можно получить забавный результат, который поможет в тестировании вашего кода:

// callback-функция для вывода информации в браузер
function backlog($script, $line, $code, $message) {
    echo "<h3>$message</h3>";
    highlight_string ($code);
}

// устанавливаем callback-функцию
assert_options(ASSERT_CALLBACK, 'backlog');
// отключаем вывод предупреждений
assert_options(ASSERT_WARNING,  false);

// пишем проверку и её описание
assert("sqr(4) == 16", "When I send integer, function should return square of it");

// функция, которую проверяем
function sqr($a) {
    return; // она не работает
}

Третий теоретический вариант – это непосредственно контрактное программирование – когда вы описали правила использования своей библиотеки, но хотите точно убедится, что вас поняли правильно, и в случае чего сразу указать разработчику на ошибку (я вот даже не уверен, что правильно его понимаю, но пример кода вполне рабочий):

/**
 * Настройки соединения должны передаваться в следующем виде
 *
 *     [
 *         'host' => 'localhost',
 *         'port' => 3306,
 *         'name' => 'dbname',
 *         'user' => 'root',
 *         'pass' => ''
 *     ]
 *
 * @param $settings
 */
function setupDb ($settings) {
    // проверяем настройки
    assert(isset($settings['host']), 'Db `host` is required');
    assert(isset($settings['port']) && is_int($settings['port']), 'Db `port` is required, should be integer');
    assert(isset($settings['name']), 'Db `name` is required, should be integer');

    // соединяем с БД
    // ...
}

setupDb(['host' => 'localhost']);

Никогда не используйте assert() для проверки входных параметров, ведь фактически assert() интерпретирует строковую переменную (ведёт себя как eval()), а это чревато PHP-инъекцией. И да, это правильное поведение, т.к. просто отключив assert’ы всё что передаётся внутрь будет проигнорировано, а если делать как в примере выше, то код будет выполняться, а внутрь отключенного assert’a будет передан булевый результат выполнения

Если у вас есть живой опыт использования assert() – поделитесь со мной, буду благодарен. И да, вот вам ещё занимательно чтива по этой теме – PHP Assertions, с таким же вопросом в конце :)

В заключение

Я за вас напишу выводы из данной статьи:

  • Ошибкам бой – их не должно быть в вашем коде
  • Используйте исключения – работу с ними нужно правильно организовать и будет счастье
  • Assert – узнали о них, и хорошо

P.S. Спасибо Максиму Слесаренко за помощь в написании статьи

Источник

Russian (Pусский) translation by Anna Goorikova (you can also view the original English article)

В этом посте вы узнаете, как использовать обработку исключений в PHP. Начиная с PHP 5, мы можем использовать блоки try catch для обработки ошибок — это лучший способ обработки исключений и управления потоком вашего приложения. В этой статье мы рассмотрим основы обработки исключений вместе с несколькими примерами из реального мира.

Что такое исключение?

В PHP 5 появилась новая модель ошибок, которая позволяет вам кидать и ловить исключения в вашем приложении — это лучший способ обработки ошибок, чем то, что мы имели в более старых версиях PHP. Все исключения являются экземплярами базового класса Exception, который мы можем расширить, чтобы ввести наши собственные пользовательские исключения.

Здесь важно отметить, что обработка исключений отличается от обработки ошибок. При обработке ошибок мы можем использовать функцию set_error_handler для установки нашей настраиваемой функции обработки ошибок, чтобы всякий раз, когда срабатывает ошибка, она вызывала нашу функцию обработки ошибок. Таким образом, вы можете управлять ошибками. Однако, как правило, некоторые виды ошибок не восстанавливаются и прекращают выполнение программы.

С другой стороны, исключения — это что-то, что умышленно вызывает код, и ожидается, что он будет пойман в какой-то момент вашего приложения. Таким образом, мы можем сказать, что исключения восстанавливаются, а не определенные ошибки, которые не подлежат восстановлению. Если исключение, которое выбрасывается, попадает где-то в ваше приложение, выполнение программы продолжается с момента, когда исключение было поймано. А исключение, которое не попадает нигде в ваше приложение, приводит к ошибке, которое останавливает выполнение программы.

Поток управления обработкой исключений

Давайте рассмотрим следующую диаграмму, которая показывает общий поток управления обработкой исключений.

Exception handling in a try catch finally blockException handling in a try catch finally blockException handling in a try catch finally block

Исключения могут быть выброшены и пойманы с помощью блоков try и catch. Вы несете ответственность за выброс исключений, если что-то произойдет, чего не ожидается. Давайте быстро рассмотрим основной поток обработки исключений, как показано в следующем псевдокоде.

1
 
// code before the try-catch block


2
 








3




try {









4




  // code










5












6




  // if something is not as expected










7




      // throw exception using the "throw" keyword










8












9




  // code, it won't be executed if the above exception is thrown










10




} catch (Exception $e) {









11




  // exception is raised and it'll be handled here










12




  // $e->getMessage() contains the error message










13




}









14












15




// code after the try-catch block, will always be executed











В большинстве случаев, когда вы имеете дело с исключениями, вы в конечном итоге используете шаблон, как показано в приведенном выше фрагменте. Вы также можете использовать блок finally вместе с блоками try и catch, но мы вернемся к этому позже в этой статье.


Блок try — тот, который используется, когда вы подозреваете, что ваш код может генерировать исключение. Вы всегда должны обертывать такой код, используя try и catch. 


Выброс исключения


Исключение может быть вызвано функцией, которую вы вызываете, или вы можете использовать ключевое слово throw для выбрасывания исключения вручную. Например, вы можете проверить некоторый ввод перед выполнением любой операции и выбросить исключение, если данные недействительны.


Здесь важно отметить, что если вы выбросите исключение, но вы не определили блок catch, который должен обрабатывать это исключение, это приведет к фатальной ошибке. Поэтому вам нужно убедиться, что вы всегда определяете блок catch, если вы бросаете исключения в своем приложении.


Когда исключение попадает в блок catch, объект Exception содержит сообщение об ошибке, которое было выбрано с использованием ключевого слова throw. Переменная $e в приведенном выше примере является экземпляром класса Exception, поэтому она имеет доступ ко всем методам этого класса. В этом блоке вы должны определить свою собственную логику обработки исключений — что именно вы хотите сделать с ошибкой, которую вы поймаете.


В следующем разделе мы рассмотрим пример из реального мира, чтобы понять, как работает обработка исключений.


Пример из реального мира


В этом разделе мы построим реальный пример для демонстрации обработки исключений в PHP.


Предположим, что вы создали приложение, которое загружает конфигурацию приложения из файла config.php. Теперь важно, чтобы файл config.php присутствовал, когда ваше приложение загружается. Таким образом, ваше приложение не может работать, если файл config.php отсутствует. Так что это идеальный случай, чтобы выбросить исключение и сообщить пользователю, что им необходимо исправить проблему.










1




<?php









2




try {









3




    // init bootstrapping phase










4












5




    $config_file_path = "config.php";









6












7




    if (!file_exists($config_file_path))









8




    {









9




      throw new Exception("Configuration file not found.");









10




    }









11




 









12




    // continue execution of the bootstrapping phase










13




} catch (Exception $e) {









14




    echo $e->getMessage();









15




    die();









16




}









17




?>











Как вы можете видеть в приведенном выше примере, мы проверяем наличие файла config.php в начале фазы начальной загрузки. Если файл config.php найден, выполнение продолжается в обычном режиме. С другой стороны, мы выбросим исключение, если файл config.php не существует. Кроме того, мы хотели бы прекратить выполнение, если есть исключение!


Вот как вы можете использовать исключения в своих приложениях. Вы должны выбрасывать исключения для исключительных случаев использования — вы не должны излишне бросать исключения для ошибок, таких как недопустимые учетные данные пользователя, неправильные разрешения на доступ к каталогам и т. д., которые вы часто ожидаете. Они лучше обрабатываются общими сообщениями об ошибках в потоке выполнения обычного приложения.


Таким образом, это был пример обработки исключений с использованием класса Exception по умолчанию. В следующем разделе мы рассмотрим, как вы можете расширить основной класс Exception и создать свои собственные пользовательские исключения в своем приложении.


Как создавать пользовательские исключения


В этом разделе мы обсудим, как вы можете создавать пользовательские исключения в своих приложениях. Фактически, мы расширим пример, который мы только что обсуждали в предыдущем разделе, чтобы продемонстрировать пользовательские исключения.


В предыдущем примере мы выбрали исключение конфигурации, используя класс Exception по умолчанию. Это прекрасно, если вы просто хотите иметь дело с сообщением об ошибке. Однако иногда вы хотите сделать немного больше в зависимости от типа исключения, которое бросается. Вот почему пользовательские исключения полезны.


Перейдем к предыдущему примеру, как показано в следующем фрагменте.










1




<?php









2




class ConfigFileNotFoundException extends Exception {}









3












4




try {









5




    // init bootstrapping phase










6












7




    $config_file_path = "config.php";









8












9




    if (!file_exists($config_file_path))









10




    {









11




      throw new ConfigFileNotFoundException("Configuration file not found.");









12




    }









13




 









14




    // continue execution of the bootstrapping phase










15




} catch (ConfigFileNotFoundException $e) {









16




    echo "ConfigFileNotFoundException: ".$e->getMessage();









17




    // other additional actions that you want to carry out for this exception










18




    die();









19




} catch (Exception $e) {









20




    echo $e->getMessage();









21




    die();









22




}









23




?>











Во-первых, мы определили класс ConfigFileNotFoundException, который расширяет основной класс Exception. Теперь он становится нашим настраиваемым классом исключений, и мы можем использовать его, когда хотим выбросить исключение ConfigFileNotFoundException в нашем приложении.


Затем мы использовали ключевое слово throw для исключения исключений ConfigFileNotFoundException в случае, если файл config.php не существует. Однако важное различие находится в блоке catch. Как вы можете видеть, мы определили два блока catch, и каждый блок используется для обнаружения различного типа исключения.


Первый получает исключения типа ConfigFileNotFoundException. Итак, если генерируемое исключение относится к типу ConfigFileNotFoundException, этот блок будет выполнен. Если тип исключения не соответствует какому-либо конкретному блоку catch, он будет соответствовать последнему, который должен поймать все генерические сообщения об исключениях.


Блок Finally


В этом разделе мы рассмотрим, как вы можете использовать ключевое слово finally вместе с блоками try и catch. Иногда вы хотите выполнить часть кода независимо от того, было ли исключено исключение. Вот где вы можете использовать блок finally, поскольку код, который вы размещаете в блоке finally, всегда будет выполняться после выполнения блоков try и catch независимо от того, было ли выбрано исключение.


Попробуем понять это, используя следующий пример.










1




try {









2




  // code










3












4




  // if something is not as expected










5




      // throw exception using the "throw" keyword










6












7




  // code, it won't be executed if the above exception is thrown










8




} catch (Exception $e) {









9




  // exception is raised and it'll be handled here










10




  // $e->getMessage() contains the error message










11




} finally {









12




  // code, it'll always be executed










13




}











Код в приведенном выше примере почти то же самое с единственным исключением, что мы добавили блок finally после блока catch. И, как мы обсуждали, код в этом блоке всегда будет выполняться.


Типичные прецеденты, которые мы могли бы придумать для использования блока finally, обычно связаны с очисткой ресурсов. Например, если вы открыли соединение с базой данных или файл на диске в блоке try, вы можете выполнять задачи очистки, такие как закрытие соединения в блоке finally, так как это гарантировано.


Обработка исключений — это ключевой навык кодирования, и вы должны подумать над тем, как будут обрабатываться исключения при разработке ваших приложений. Это поможет вам обнаружить и восстановить непредвиденные ошибки в вашем приложении. Надеюсь, что этот пост вдохновит вас написать лучший код обработки ошибок!


Заключение


Сегодня мы обсудили тему обработки исключений в PHP. В первой половине статьи мы обсудили основы исключений в PHP и создали реальный пример, чтобы продемонстрировать, как они работают. В конце мы рассмотрели, как вы можете создавать пользовательские исключения, расширяя основной класс Exception.






Источник






Prerequisite: Types of Error 
PHP is used for web development. Error handling in PHP is almost similar to error handling in all programming languages. The default error handling in PHP will give file name line number and error type.
 


Ways to handle PHP Errors:  


    

  • Using die() method
    • 

  • Custom Error Handling
    • 



Basic error handling: Using die() function The die() function print a message and exit from current script.
Syntax:  


die( $message )


Example:  




php




<?php


$file = fopen("geeks.txt", "w");


?>






Note: Run the above code and geeks.txt file is not present then it will display an run-time error message. 
Runtime Error: 


 PHP Warning: fopen(geeks.txt): failed to open stream: Permission denied 
in /home/dac923dff0a2558b37ba742613273073.php on line 2


To prevent this error use die() function. Below is the implementation of die() function:
Example:  




php




<?php


if( !file_exists("geeks.txt") ) {


    die("File is not present");


}


else {


    $file = fopen("geeks.txt", "w");


}


?>






Note: If geeks.txt file not present then it will display output. 
Output 


File is not present


Custom Error handling: Creating a custom error handler in PHP is quite simple. Create a function that can be called when a error has been occurred in PHP.
Syntax:  


error_function( $error_level, $error_message, $error_file, $error_line, $error_context)


Parameters: This function accepts five parameters as mentioned above and described below:  


    

  • $error_level: It is required parameter and it must be an integer. There are predefined error levels.
    • 

  • $error_message: It is required parameter and it is the message which user want to print.
    • 

  • $error_file: It is optional parameter and used to specify the file in which error has been occurred.
    • 

  • $error_line: It is optional parameter and used to specify the line number in which error has been occurred.
    • 

  • $error_context: It is optional parameter and used to specify an array containing every variable and their value when error has been occurred.
    • 



error_level: These are the possible error level which are listed below: 


    

  • 1 : .E_ERROR :fatal runtime error execution of script has been halted
    • 

  • 2 : E_WARNING :non fatal runtime error execution of script has been halted
    • 

  • 4 : E_PARSE :compile time error it is generated by the parser
    • 

  • 8 :E_NOTICE :The script found something that might be an error
    • 

  • 16 :E_CORE_ERROR :Fatal errors that occurred during initial startup of script
    • 

  • 32 :E_CORE_WARNING :Non fatal errors that occurred during initial startup of script
    • 

  • 8191 :E_ALL :All errors and warning
    • 



set_error_handler() Function: After creating myerror() function need to set custom error handler because in normal way PHP handles it but if user doing custom error handling then user have to set it in place of argument and pass out myerror function as a string.
Example: 




php




<?php


function myerror($error_no, $error_msg) {


    echo "Error: [$error_no] $error_msg ";


    echo "n Now Script will end";


    die();


}


set_error_handler("myerror");


$a = 10;


$b = 0;


echo($a / $b);;


?>






Output: 


Error: [2] Division by zero 
 Now Script will end


Conclusion: It is always try to error handling using Custom error handling because it will show more specified message according to the user that can be helpful to the user. If error is not handle using Custom error handling then a error occurred then out script will be halted by default but if it handle error using Custom error handling then it can continue script after displaying error message.






Last Updated :

21 Nov, 2021


Like Article



Save Article







Источник






В целом ваша механика отлова ошибок верная, потому мне не очень понятна критика вашего товарища. Было бы здорово взглянуть на его решение.


Теперь по существу. Собственно, класс обработчик ошибок:


class ErrorHandler
{
    protected $format = '{{message}} {{class}}::{{method}} {{file}} on line {{line}}';
    /**
     * @var HandlerInterface
     */
    protected $displayHandler;

    /**
     * @var integer the size of the reserved memory. A portion of memory is pre-allocated so that
     * when an out-of-memory issue occurs, the error handler is able to handle the error with
     * the help of this reserved memory. If you set this value to be 0, no memory will be reserved.
     * Defaults to 256KB.
     */
    protected $memoryReserveSize = 262144;
    /**
     * @var string Used to reserve memory for fatal error handler.
     */
    private $_memoryReserve;

    /**
     * Register this error handler.
     */
    public function register()
    {
        // Catch errors
        set_error_handler([$this, 'handleError']);

        if ($this->memoryReserveSize > 0) {
            $this->_memoryReserve = str_repeat('x', $this->memoryReserveSize);
        }
        // Start buffer
        ob_start();
        // Catch fatal errors
        register_shutdown_function([$this, 'handleShutdown']);
    }

    /**
     * Unregisters this error handler by restoring the PHP error handlers.
     */
    public function unregister()
    {
        restore_error_handler();
    }

    /**
     * Error handler.
     *
     * @param int $code
     * @param string $msg
     * @param string $file
     * @param int $line
     * @return bool
     * @throws ErrorException
     */
    public function handleError($code, $msg, $file, $line)
    {
        if (~error_reporting() & $code) {
            return false;
        }

        switch ($code) {
            case E_USER_WARNING:
            case E_WARNING:
                $exception = new ErrorException("[E_WARNING] {$msg}", Log::WARNING, $code, $file, $line);
                break;
            case E_USER_NOTICE:
            case E_NOTICE:
            case E_STRICT:
                $exception = new ErrorException("[E_NOTICE] {$msg}", Log::NOTICE, $code, $file, $line);
                break;
            case E_RECOVERABLE_ERROR:
                $exception = new ErrorException("[E_CATCHABLE] {$msg}", Log::ERROR, $code, $file, $line);
                break;
            default:
                $exception = new ErrorException("[E_UNKNOWN] {$msg}", Log::CRITICAL, $code, $file, $line);
        }

        throw $exception;
    }

    /**
     * Fatal handler.
     *
     * @return void
     */
    public function handleShutdown()
    {
        unset($this->_memoryReserve);

        $error = error_get_last();
        if (
            isset($error['type']) &&
            ($error['type'] == E_ERROR ||
                $error['type'] == E_PARSE ||
                $error['type'] == E_COMPILE_ERROR ||
                $error['type'] == E_CORE_ERROR)
        ) {

            $type = "";
            switch ($error['type']) {
                case E_ERROR:
                    $type = '[E_ERROR]';
                    break;
                case E_PARSE:
                    $type = '[E_PARSE]';
                    break;
                case E_COMPILE_ERROR:
                    $type = '[E_COMPILE_ERROR]';
                    break;
                case E_CORE_ERROR:
                    $type = '[E_CORE_ERROR]';
                    break;
            }
            $exception = new ErrorException("$type {$error['message']}", Log::CRITICAL, $error['type'], $error['file'], $error['line']);
            if (APP_LOG) {
                Log::log(Log::CRITICAL, $this->convertExceptionToString($exception));
            }
            $this->display($exception);
        } else {
            if (ob_get_length() !== false) {
                // Display buffer, complete work buffer
                ob_end_flush();
            }
        }
    }

    /**
     * Sets a display handler.
     * @param HandlerInterface $handler
     */
    public function setDisplayHandler(HandlerInterface $handler)
    {
        $this->displayHandler = $handler;
    }

    /**
     * Sets a format message log.
     * @param string $format
     */
    public function setFormat($format)
    {
        $this->format = $format;
    }

    /**
     * Sets a size memory.
     * @param int $size
     */
    public function setMemoryReserve($size)
    {
        $this->memoryReserveSize = $size;
    }

    /**
     * @param Exception $exception
     */
    public function display(Exception $exception)
    {
        // display Whoops
        if (APP_DEBUG === true) {
            if (!isset($this->displayHandler)) {
                $this->displayHandler = new PrettyPageHandler();
            }
            $run = new Run();
            $run->pushHandler($this->displayHandler);
            $run->handleException($exception);
            return;
        }

        die('This site is temporarily unavailable. Please, visit the page later.');
    }

    /**
     * Converts an exception into a simple string.
     *
     * @param Exception $exception the exception being converted
     * @return string the string representation of the exception.
     */
    public function convertExceptionToString(Exception $exception)
    {
        $trace = $exception->getTrace();
        $placeholders = [
            '{{class}}' => isset($trace[0]['class']) ? $trace[0]['class'] : '',
            '{{method}}' => isset($trace[0]['function']) ? $trace[0]['function'] : '',
            '{{message}}' => $exception->getMessage(),
            '{{file}}' => $exception->getFile(),
            '{{line}}' => $exception->getLine(),
        ];

        return strtr($this->format, $placeholders);
    }
}





Класс может быть и статическим (т.е. содержать статические методы и свойства). Не имеет значения.




За отображение исключений и ошибок в красивом интерфейсе отвечает вполне известная библиотека Whoops, а логирование производится с помощью Monolog (здесь представлен лёгенький wrapper над ней)


Существуют различные нюансы, к примеру, для отлова фатала связанного с переполнением памяти (Allowed memory size of...), необходимо зарезервировать некий объём. Опытным путём был рассчитан объём в 256KB. Об этом я узнал на одной из конференции от Александра samdark Макарова (евангелист и мэйнтейнер фреймворка yii). Собственно, в обработчике фреймворка подобный хак имеется. Если проанализировать код обработчика yii2, то можно заментить другие нюансы связанные, к примеру, с обработкой ошибок/исключений HHVM.


В единой точке входна в ваше приложение (index.php) указываем следующее:


defined('APP_DEBUG') or define('APP_DEBUG', true);
defined('APP_LOG') or define('APP_LOG', true);

$errorHandler = new ErrorHandler;
$errorHandler->register();

try {

  // ... bootstrap вашего приложения

} catch (Exception $e) {
    if (APP_LOG) {
        $msg = $errorHandler->convertExceptionToString($e);
        Log::log($e->getCode() ? : Log::CRITICAL, $msg);
    }
    $errorHandler->display($e);
}



В самом приложение можно ловить локальные исключения и делать с ними всё что угодно. К примеру, ловить и тут же логировать:


try {

    // ... некая локальная логика приложения

} catch (Exception $e) {
    Log::log(Log::ERROR, (new ErrorHandler())->convertExceptionToString($e));
}



Так или иначе, любое выбрашенное исключение будет отловлено в index.php и в зависимости от заданных констант (APP_DEBUG и APP_LOG) представленно в красивом интерфейсе и добавлено в лог. Естественно на продакшене стоит обязательно отключить режим дебага.


По поводу обработчиков Whoops:


Зная в каком формате (content type) вам необходимо отдать данные пользователю, можно выбрать подходящий обработчик.


К примеру, проверка является ли запрос ajax-запросом


if (isset($_SERVER['HTTP_X_REQUESTED_WITH']) && $_SERVER['HTTP_X_REQUESTED_WITH'] === 'XMLHttpRequest') {
   $errorHandler->setDisplayHandler(new JsonResponseHandler());
}



Дебаг-информация будет представлена в виде json-а, что удобно для просмотра через консоль браузера.


В идеале необходимо иметь HTTP прослойку (классы Response/Request) и всё это детектить на уровне роутинга или фильтров/поведений контроллера — ContentNegotiator или что-то подобное.


P.S. Посмотрите видео холивара про оператор подавления ошибок @ с devconf. Очень занимательно.




UPDATE


Я лично в проектах стараюсь возвращать верные http-статусы. Вам никто не мешает выдать пользовотелю специально оформленную 404-страницу с аналогичным статусом.


if (headers_sent()) { // проверка: не отправлены ли уже заголовоки
   return;
}
$version = isset($_SERVER['SERVER_PROTOCOL']) && $_SERVER['SERVER_PROTOCOL'] === 'HTTP/1.0' ? '1.0' : '1.1'
$statusCode = 404;
$statusText = 'Not Found';

header("HTTP/$version $statusCode $statusText");





Как я уже отмечал ранее, лучше всего использовать класс-прослойку Response над нативными функциями.




С роутингом этого добиться досточно просто:


$route = new Route(); 
$route->get('/items/{id:d+}/', ['namespaceItemsController', 'actionOne']);
$route->post('/items/', ['namespaceItemsController', 'actionCreate']);
//... другие правила
$route->any('*', ['namespaceItemsController', 'actionNotFound']);
// т.е. если вышеприведенные правила не выполнились, то выполнится последнее правило.



Для ajax-запрос, достаточно в ответе указать заголовок без тела:


$route->any('*', function(Route $route) {
   $route->response->status404();
   return $route->response;
});



403 — если доступ к ресурсу (по какому-то URL-у) запрещен для неавторизованного пользователя или пользователя с иной ролью/правами, к примеру, не имеющего права администратора. Посмотрите RBAC. В yii подобный механизм реализован через поведения/фильтры к экшенам контроллера.


201 — ресурс успешно создан. К примеру, можно выдавать, когда зарегистрирован пользователь, создан комментарий или пост.


204 — запрос к БД завершился успешно, но данные по какой-то причине отсутствуют. К примеру, открылся новый раздел на сайте, но статьи для него ещё не написаны.


422 я использую, если не прошла валидация данных, к примеру формы. В данном случае, через $statusText (см. выше), можно дать пояснение: Validation failure.


429 — классический rate limiter. Чаще всего применятеся для REST API. При достижении определённого лимита на количтво запросов выдавать данный статус.


302 — при редиректе. К примеру, если данные пришедшие от формы верны и запись в БД успешно произведена, то проивзодится редирект на стороннюю страницу, либо рефреш текущий страницы с данным статус.


500 — если вы могли заметить, то в ErrorHandler имеется die('This site is temporarily unavailable. Please, visit the page later.');. Вы можете вместо этой «пресной» записи выдать пользователю статичную страницу-заглушку предварительно указав http-статус 500. 


die(file_get_contents('/path/to/stub.html'));





Для реализации своего RESTful API указание верныx http-методов, статусов, заголовков (почитайте про HATEOAS) является обязательных.




Полный список статусов


Таким образом, в режиме дебага у вас будет выводится Whoops со стек-трейсом, а на продакшене (боевом сервере) пользователю будет показана заглушка. Логировать или нет ошибки/исключения на ваше усмотрение. К примеру, во многих фреймворках по умолчанию производлится «информационное» логирование (level Log::INFO), т.е. каждое соединие с БД, успешность транзакций, авторизация пользователя и т.д., что хорошенько может так забить ваш накопитель на сервере. Необходимо повышать уровень логирования ошибок до Log::WARNING или Log::ERROR, а также использоватать штатные утилиты по ротации логов. К примеру, в Linux это logrotate.


Коль я затронул тут множество тем, то позвольте прорекламировать мои open source библиотеки:


    

  • Rock Route — роутинг с гибкими правилами, группировкой (разделение правил на пространства/модули для, к примеру, ajax, backend/админка и т.д., как в laravel) и поддержкой REST. Алгоритм реализации облегчённых regexp-паттернов был взят из библиотеки FastRoute Никиты Попова (входит в core team PHP). Имеется подробная документация.
    • 

  • Rock Response — форк yii2 response, который полностью отделён от фреймворка. Документации, к сожалению нет, но существует официальная документации yii. Правда, тоже пока короткая.
    

    

    Как мы знаем yii2 является монолитным фреймворком.
    

    

    • 

  • Rock Request — аналогичный форк, но с моей библиотекой фильтрации данный.
    • 



Все указанные библиотеки идут без лишних зависимостей — всё только самое необходимое для их работы.






Источник






Иногда ваше приложение не запускается должным образом, что приводит к ошибкам. Есть ряд причин, которые могут вызвать ошибки, например:


    

  • Веб-серверу может не хватить места на диске;
    • 

  • Пользователь мог ввести недопустимое значение в поле формы;
    • 

  • Файл или запись базы данных, к которой вы пытались получить доступ, возможно, не существует;
    • 

  • Приложение может не иметь разрешения на запись в файл на диске;
    • 

  • Служба, к которой приложение должно получить доступ, может быть временно недоступна.
    • 



Эти типы ошибок известны как ошибки времени выполнения, потому что они возникают во время выполнения скрипта. Они отличаются от синтаксических ошибок, которые необходимо исправлять перед запуском скриптов.


Профессиональное приложение должно иметь возможность изящно обрабатывать такие ошибки времени выполнения. Обычно это означает более четкое и точное информирование пользователя о проблеме.


Понимание уровней ошибок


Обычно, когда возникает проблема, препятствующая правильной работе скрипта, механизм PHP выдает ошибку. Каждая ошибка представлена целым числом и соответствующей константой. В следующей таблице перечислены некоторые из распространенных уровней ошибок:






Название
Значение
Описание




E_ERROR
1
Неустранимая ошибка времени выполнения от которой невозможно избавиться. Выполнение скрипта немедленно прекращается.




E_WARNING
2
Предупреждение во время выполнения. Она несущественна, и большинство ошибок попадают в эту категорию. Выполнение скрипта не останавливается.




E_NOTICE
8
Уведомление во время выполнения. Указывает, что скрипт обнаружил что-то, что могло быть ошибкой, хотя такая ситуация также может возникнуть при обычном запуске скрипта.




E_USER_ERROR
256
Сообщение о фатальной пользовательской ошибке. Она похожа на E_ERROR, за исключением того, что она генерируется PHP-скриптом с использованием функции trigger_error().




E_USER_WARNING
512
Предупреждающее сообщение, созданное пользователем без фатального исхода. Она похожа на E_WARNING, за исключением того, что она генерируется PHP-скриптом с использованием функции trigger_error().




E_USER_NOTICE
1024
Сообщение с уведомлением, созданное пользователем. Она похожа на E_NOTICE за исключением того, что она генерируется PHP-скриптом с использованием функции trigger_error().




E_STRICT
2048
Не совсем ошибка, но срабатывает всякий раз, когда PHP встречает код, который может привести к проблемам или несовместимости пересылки.




E_ALL
8191
Все ошибки и предупреждения, кроме E_STRICT до PHP 5.4.0.






Дополнительные сведения об уровнях ошибок см. в справочнике по уровням ошибок PHP.


Механизм PHP вызывает ошибку всякий раз, когда он сталкивается с проблемой в вашем скрипте, но вы также можете инициировать ошибки самостоятельно, чтобы генерировать более удобные сообщения об ошибках. Таким образом вы можете сделать свое приложение более сложным. В следующем разделе описаны некоторые из распространенных методов, используемых для обработки ошибок в PHP:


Базовая обработка ошибок с помощью функции die()


Рассмотрим следующий пример, в котором просто попытаемся открыть текстовый файл только для чтения.


<?php
// Пробуем открыть несуществующий файл
$file = fopen("sample.txt", "r"); // Выводит: Warning: fopen(sample.txt) [function.fopen]: failed to open stream: No such file or directory in C:wampwwwprojecttest.php on line 2
?>


Если мы выполним несколько простых шагов, мы сможем предотвратить получение пользователями такого сообщения об ошибке.


<?php
if(file_exists("sample.txt")){
    $file = fopen("sample.txt", "r");
} else{
    die("Error: The file you are trying to access doesn't exist.");
}
?>


Как вы можете видеть, реализовав простую проверку, существует ли файл перед попыткой доступа к нему, мы можем сгенерировать сообщение об ошибке, которое будет более понятным для пользователя.


Используемая выше функция die() просто отображает пользовательское сообщение об ошибке и завершает текущий скрипт, если файл sample.txt не найден.


Создание собственного обработчика ошибок


Вы можете создать свою собственную функцию обработчика ошибок, чтобы справляться с ошибкой времени выполнения, генерируемой механизмом PHP. Пользовательский обработчик ошибок обеспечивает большую гибкость и лучший контроль над ошибками; он может проверять ошибку и решать, что с ней делать — отображать сообщение пользователю, регистрировать ошибку в файле или базе данных или отправлять по электронной почте, попытаться исправить проблему и продолжить, выйти из выполнения скрипта или вообще игнорировать ошибку.


Функция пользовательского обработчика ошибок должна иметь возможность обрабатывать как минимум два параметра (errno и errstr), однако она может дополнительно принимать три дополнительных параметра (errfile, errline и errcontext), как описано ниже:






Параметр
Описание




Обязательно — следующие параметры обязательны




errno.
Задает уровень ошибки в виде целого числа. Это соответствует соответствующей константе уровня ошибки (E_ERROR, E_WARNING и т. д.).




errstr.
Задает сообщение об ошибке в виде строки.




Опционально — следующие параметры являются необязательными




errfile.
Задает имя файла скрипта, в котором произошла ошибка.




errline.
Задает номер строки, в которой произошла ошибка.




errcontext.
Задает массив, содержащий все переменные и их значения, которые существовали на момент возникновения ошибки. Полезно для отладки.






Вот пример простой пользовательской функции обработки ошибок. Этот обработчик customError() запускается всякий раз, когда возникает ошибка, какой бы тривиальной она ни была. Затем он выводит сведения об ошибке в браузер и останавливает выполнение скрипта.


<?php
// Функция обработчика ошибок
function customError($errno, $errstr){
    echo "<b>Error:</b> [$errno] $errstr";
}
?>


Вам нужно указать PHP, чтобы он использовал вашу пользовательскую функцию обработчика ошибок — просто вызовите встроенную функцию set_error_handler(), передав имя функции.


<?php
// Функция обработчика ошибок
function customError($errno, $errstr){
    echo "<b>Error:</b> [$errno] $errstr";
}
 
// Устанавливаем обработчик ошибок
set_error_handler("customError");
 
// Вызываем ошибку
echo($test);
?>


Регистрация ошибок


Журнал сообщений об ошибках в текстовом файле


Вы также можете записать подробную информацию об ошибке в файл журнала, например:


<?php
function calcDivision($dividend, $divisor){
    if($divisor == 0){
        trigger_error("calcDivision(): The divisor cannot be zero", E_USER_WARNING);
        return false;
    } else{
        return($dividend / $divisor);
    }
}
function customError($errno, $errstr, $errfile, $errline, $errcontext){
    $message = date("Y-m-d H:i:s - ");
    $message .= "Error: [" . $errno ."], " . "$errstr in $errfile on line $errline, ";
    $message .= "Variables:" . print_r($errcontext, true) . "rn";
    
    error_log($message, 3, "logs/app_errors.log");
    die("There was a problem, please try again.");
}
set_error_handler("customError");
echo calcDivision(10, 0);
echo "This will never be printed.";
?>


Отправка сообщений об ошибках по электронной почте


Вы также можете отправить электронное письмо с подробностями об ошибке, используя ту же функцию error_log().


<?php
function calcDivision($dividend, $divisor){
    if ($divisor == 0){
        trigger_error("calcDivision(): The divisor cannot be zero", E_USER_WARNING);
        return false;
    } else{
        return($dividend / $divisor);
    }
}
function customError($errno, $errstr, $errfile, $errline, $errcontext){
    $message = date("Y-m-d H:i:s - ");
    $message .= "Error: [" . $errno ."], " . "$errstr in $errfile on line $errline, ";
    $message .= "Variables:" . print_r($errcontext, true) . "rn";
    
    error_log($message, 1, "webmaster@example.com");
    die("There was a problem, please try again. Error report submitted to webmaster.");
}
set_error_handler("customError");
echo calcDivision(10, 0);
echo "This will never be printed.";
?>


Вызов ошибок


Хотя движок PHP выдает ошибку всякий раз, когда он сталкивается с проблемой в вашем скрипте, вы также можете вызвать ошибки самостоятельно. Это может помочь сделать ваше приложение более надежным, поскольку оно может выявлять потенциальные проблемы до того, как они перерастут в серьезные ошибки.


Чтобы вызвать ошибку в скрипте, вызовите функцию trigger_error(), передав сообщение об ошибке, которое вы хотите сгенерировать:


trigger_error("There was a problem.");


Рассмотрим следующую функцию, которая вычисляет деление двух чисел.


<?php
function calcDivision($dividend, $divisor){
    return($dividend / $divisor);
}
 
// Вызываем функцию
echo calcDivision(10, 0); // Выводит: Warning: Division by zero in C:wampwwwprojecttest.php on line 3
?>


Это сообщение выглядит не очень информативным. Рассмотрим следующий пример, в котором для генерации ошибки используется функция trigger_error().


<?php
function calcDivision($dividend, $divisor){
    if($divisor == 0){
        trigger_error("Делитель не может быть нулевым", E_USER_WARNING);
        return false;
    } else{
        return($dividend / $divisor);
    }
}
 
// Вызываем функцию
echo calcDivision(10, 0); // Выводит: Warning: Делитель не может быть нулевым C:wampwwwprojecterror.php on line 4
?>


Как видите, сообщение об ошибке, созданное во втором примере, более четко объясняет проблему по сравнению с предыдущим.






Источник






Обработка исключений


Конструкция try catch finally


Последнее обновление: 24.03.2021


В процессе работы программы могут возникать различные ошибки, которые могут прервать работу программы. Например, рассмотрим следующую ситуацию:


$a = 5;
$b = 0;
$result = $a / $b;
echo $result;
echo "Конец работы программы";



Программа выводит результат деления. Поскольку делитель равен 0, а на ноль делить нельзя, то при выполнении деления программа завершится, и в браузере мы увидим

что-то типа следующего:


Fatal error: Uncaught DivisionByZeroError: Division by zero in D:localhosthello.php:11 Stack trace: #0 {main} thrown in D:localhosthello.php on line 11



Браузер отобразит нам произошедшую ошибку, причем дальше после строки с делением программа даже не будет выполняться.


Кто-то может сказать, что ситуация искуственная, так как мы сами определили делитель равный нулю. Но данные могут передаваться извне. Кроме того, кроме деления на ноль есть различные

ситуации, при которых могут происходить ошибки. Но PHP предоставляет ряд возможностей для обработки подобных ситуаций.


Для обработки исключений в PHP применяется конструкция try-catch:


try
{
	// код, который может вызвать исключение
}
catch(Тип_исключения $ex)
{
	// обработка исключения
}



Эта конструкция в общем варианте состоит из двух блоков — try и catch. В блок try помещается код, который потенциально может вызвать исключение.

А в блоке catch помещается обработка возникшего исключения. Причем каждого типа исключения мы можем определить свою логику обработки. Конкретный тип исключения,

который мы хотим обработать, указывается в круглых скобках после оператора catch:


catch(Тип_исключения $ex)


После названия типа указывается переменная этого типа (в данном случае $ex), которая будет хранить информацию об исключении и которую мы можем использовать

при обработке исключения.


Если в блоке try при выполнении кода возникает ошибка, то блок try прекращает выполнение и передает управление блоку catch, который обрабатывает ошибку.

А после завершения выполнения кода в блоке catch программа продолжает выполнять инструкции, которые размещены после блока catch.


Если в блоке try при выполнении кода не возникает ошибок, то блок catch не выполняется, а после завершения блока try

программа продолжает выполнять инструкции, которые размещены после блока catch.


Например, обработаем ошибку с делением на ноль:


try
{
	// код, который может вызвать исключение
	$a = 5;
	$b = 0;
	$result = $a / $b;
	echo $result;
}
catch(DivisionByZeroError $ex)
{
	// обработка исключения
	echo "Произошло исключение:<br>";
	echo $ex . "<br>";
}
echo "Конец работы программы";



В данном случае код деления на ноль, поскольку он может потенциально вызвать ошибку, помещен в блок try.


В блоке catch обрабатывается ошибка типа DivisionByZeroError, которая генерируется при делении на ноль. Вся обработка сводится

к выводу информации на экран.


В итоге при выполнении программа выведет следующее:


Произошло исключение:
DivisionByZeroError: Division by zero in D:localhosthello.php:14 Stack trace: #0 {main}
Конец работы программы



Как видно из вывода программы, она не завершается аварийно при делении на ноль, а продолжает работу.


Типы ошибок и исключений


В PHP для разных ситуаций есть множество типов, которые описывают ошибки. Все эти встроенные типы применяют интерфейс Throwable:


Ошибки и исключения Error, Exception и Throwable в PHP


Все типы делятся на две группы: собственно ошибки (класс Error) и собственно исключения (класс Exception).

А от классов Error и Exception наследуются классы ошибок и исключений, которые описывают конкретные ситуации. Например, от класса

Error наследуется класс ArithmeticError, который описывает ошибки, возникающие при выполнении арифметических операций.

А от класса ArithmeticError наследуется класс DivisionByZeroError, который представляют ошибку при делении на ноль.


Блок catch


Конструкция try..catch позволяет определить несколько блоков catch — для обработки различных типов ошибок и исключений:


try
{
	$result = 5 / 0;
	echo $result;
}
catch(ParseError $p)
{
    echo "Произошла ошибка парсинга";
}
catch(DivisionByZeroError $d)
{
	echo "На ноль делить нельзя";
}



При возникновении ошибки будет для ее обработки будет выбираться тот блок catch, который соответствует вошникшей ошибки. Так, в данном случае

при делении на ноль будет выполняться второй блок catch.


Если бы в блоке try возникла бы ошибка, которая бы не соответствовала типам из блоков catch (в данном случае — типам DivisionByZeroError и ParseError),

то такая ошибка не была бы обработана, и соответственно программа бы аварийно завершила свое выполнение.


Блоки catch с более конкретными типами ошибок и исключений должны идти в начале, а более с более общими типа — в конце:


try
{
	$result = 5 / 0;
	echo $result;
}
catch(DivisionByZeroError $ex)
{
	echo "На ноль делить нельзя";
}
catch(ArithmeticError $ex)
{
	echo "Ошибка при выполнении арифметической операции";
}
catch(Error $ex)
{
	echo "Произошла ошибка";
}
catch(Throwable $ex)
{
	echo "Ошибка при выполнении программы";
}



Класс DivisionByZeroError унаследован от ArithmeticError, который, в свою очередь, унаследован от Error, реализующего интерфейс Throwable. Поэтому

класс DivisionByZeroError представляет более конкретный тип и представляемые им ошибки должны обрабатываться в первую очередь. А тип Throwable представляет

наиболее общий тип, так как ему соответствуют все возможные ошибки и исключения, поэтому блоки catch с таким типом должны идти в конце.


В данном случае опять же в блоке try происходит ошибка деления на ноль. Но этой ошибке соответствуют все четыре блока catch. Для обработки PHP будет

выбирать первый попавшийся, который соответствует типу ошибки. В данном случае это блок для обработки ошибки типа DivisionByZeroError.


Если нам надо обрабатывать в принципе все ошибки и исключения, то мы можем определить только обработку общего для всех них типа Throwable:


try
{
	$result = 5 / 0;
	echo $result;
}
catch(Throwable $ex)
{
	echo "Ошибка при выполнении программы";
}



Начиная с версии PHP 8.0 в блоке catch можно просто указать тип обрабатываемого исключения, не определяя переменную:


catch(DivisionByZeroError)
{
	echo "Произошло исключение: деление на ноль";
}



Получение информации об ошибках и исключениях


Интерфейс Throwable предоставляет ряд методов, которые позволяют получить некоторую информацию о возникшем исключении:


    

  • 

    getMessage(): возвращает сообщение об ошибке
    

    • 

  • 

    getCode(): возвращает код исключения
    

    • 

  • 

    getFile(): возвращает название файла, в котором возникла ошибка
    

    • 

  • 

    getLine(): возвращает номер строки, в которой возникла ошибка
    

    • 

  • 

    getTrace(): возвращает трассировку стека
    

    • 

  • 

    getTraceAsString(): возвращает трассировку стека в виде строки
    

    • 



Применим некоторые из этих методов:


try
{
	$result = 5 / 0;
	echo $result;
}
catch(DivisionByZeroError $ex)
{
	echo "Сообщение об ошибке: " . $ex->getMessage() . "<br>";
	echo "Файл: " . $ex->getFile() . "<br>";
	echo "Номер строки: " . $ex->getLine() . "<br>";
}



Результат работы:


Сообщение об ошибке: Division by zero
Файл: D:localhosthello.php
Номер строки: 11



Блок finally


Конструкция try..catch также может определять блок finally. Этот блок выполняется в конце — после блока try и catch

вне зависимости, возникла или нет ошибка. Нередко блок finally используется для закрытия ресурсов, которые применяются в блоке try.


try
{
	$result = 5 / 0;
	echo $result . "<br>";
}
catch(Throwable $ex)
{
	echo "Ошибка при выполнении программы<br>";
}
finally
{
	echo "Блок finally<br>";
}
echo "Конец работы программы";



Вывод программы:


Ошибка при выполнении программы
Блок finally
Конец работы программы



Конструкция try..catch..finally может содержать либо все три блока, либо только два блока try и либо блок catch,

либо блок finally.






Источник







  



                       
  





	









    
    
    
    



    

                
Понравилась статья? Поделить с друзьями:

        
        

























    




Не пропустите эти материалы по теме: 




  • Яндекс еда ошибка привязки карты
    • 

  • Как правильно надо делать работу над ошибками
    • 

  • Как правильно логировать ошибки
    • 

  • Как правильно кадастровая ошибка или реестровая ошибка
    • 

  • Как правильно исправить реестровую ошибку

    • 











    
    
    
    
            
    
            
    
            
    
                
    
                    0
                    0
                    голоса
    
                
    Рейтинг статьи
    
                
    
            
        
    
                    
    
                            
    
            
    
                
    
                                            
    
                             Подписаться
                            
                        
    
                                            
    
                                                
                    
    
                
    
                                                    
    
                                                    
    
                                
    Уведомить о 
    
                                
    
                                    
                                
    
                                                                    
                                                                    
    
                                    
                                
    
                                                            
    
                                                
    
                            
    
                                        
    
                                        
    
                        
    
                            
    
                                                                                                        
    
                                        guest                                    
    
                                                
                                        
    
                        
    
                    
    
                    
                                        
                    
                    
    
                        
    
                
                    
    
                        
    
                
    
                    
    
                        0 комментариев                    
    
                                        
    
                    
    
                                                    
    
                                
    
                                                        
    
                                
    
                                                        
    
                                                                        Старые
                                                                        
                                
    
                                                                            Новые
                                                                                Популярные
                                                                        
    
                            
    
                                                
    
                
    
                
    
                    
     Межтекстовые Отзывы                     
    
                    
    Посмотреть все комментарии