Php генерация ошибки

Table of Contents

  • Extending Exceptions

PHP has an exception model similar to that of other programming
languages. An exception can be thrown, and caught («catched») within
PHP. Code may be surrounded in a try block, to facilitate the catching
of potential exceptions. Each try must have at least one corresponding
catch or finally block.

If an exception is thrown and its current function scope has no catch
block, the exception will «bubble up» the call stack to the calling
function until it finds a matching catch block. All finally blocks it encounters
along the way will be executed. If the call stack is unwound all the way to the
global scope without encountering a matching catch block, the program will
terminate with a fatal error unless a global exception handler has been set.

The thrown object must be an instanceof Throwable.
Trying to throw an object that is not will result in a PHP Fatal Error.

As of PHP 8.0.0, the throw keyword is an expression and may be used in any expression
context. In prior versions it was a statement and was required to be on its own line.

catch

A catch block defines how to respond to a thrown exception. A catch
block defines one or more types of exception or error it can handle, and
optionally a variable to which to assign the exception. (The variable was
required prior to PHP 8.0.0.) The first catch block a thrown exception
or error encounters that matches the type of the thrown object will handle
the object.

Multiple catch blocks can be used to catch different classes of
exceptions. Normal execution (when no exception is thrown within the try
block) will continue after that last catch block defined in sequence.
Exceptions can be thrown (or re-thrown) within a catch block. If not,
execution will continue after the catch block that was triggered.

When an exception is thrown, code following the statement will not be
executed, and PHP will attempt to find the first matching catch block.
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().

As of PHP 7.1.0, a catch block may specify multiple exceptions
using the pipe (|) character. This is useful for when
different exceptions from different class hierarchies are handled the
same.

As of PHP 8.0.0, the variable name for a caught exception is optional.
If not specified, the catch block will still execute but will not
have access to the thrown object.

finally

A finally block may also be specified after or
instead of catch blocks. Code within the finally block will always be
executed after the try and catch blocks, regardless of whether an
exception has been thrown, and before normal execution resumes.

One notable interaction is between the finally block and a return statement.
If a return statement is encountered inside either the try or the catch blocks,
the finally block will still be executed. Moreover, the return statement is
evaluated when encountered, but the result will be returned after the finally block
is executed. Additionally, if the finally block also contains a return statement,
the value from the finally block is returned.

Global exception handler

If an exception is allowed to bubble up to the global scope, it may be caught
by a global exception handler if set. The set_exception_handler()
function can set a function that will be called in place of a catch block if no
other block is invoked. The effect is essentially the same as if the entire program
were wrapped in a trycatch block with that function as the catch.

Notes

Note:

Internal PHP functions mainly use
Error reporting, only modern
Object-oriented
extensions use exceptions. However, errors can be easily translated to
exceptions with ErrorException.
This technique only works with non-fatal errors, however.

Example #1 Converting error reporting to exceptions


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

Examples

Example #2 Throwing an Exception


<?php
function inverse($x) {
if (!
$x) {
throw new
Exception('Division by zero.');
}
return
1/$x;
}

try {
echo

inverse(5) . "n";
echo
inverse(0) . "n";
} catch (
Exception $e) {
echo
'Caught exception: ', $e->getMessage(), "n";
}
// Continue execution
echo "Hello Worldn";
?>

The above example will output:

0.2
Caught exception: Division by zero.
Hello World

Example #3 Exception handling with a finally block


<?php
function inverse($x) {
if (!
$x) {
throw new
Exception('Division by zero.');
}
return
1/$x;
}

try {
echo

inverse(5) . "n";
} catch (
Exception $e) {
echo
'Caught exception: ', $e->getMessage(), "n";
} finally {
echo
"First finally.n";
}

try {
echo

inverse(0) . "n";
} catch (
Exception $e) {
echo
'Caught exception: ', $e->getMessage(), "n";
} finally {
echo
"Second finally.n";
}
// Continue execution
echo "Hello Worldn";
?>

The above example will output:

0.2
First finally.
Caught exception: Division by zero.
Second finally.
Hello World

Example #4 Interaction between the finally block and return


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

echo

test();
?>

The above example will output:

Example #5 Nested Exception


<?phpclass MyException extends Exception { }

class

Test {
public function
testing() {
try {
try {
throw new
MyException('foo!');
} catch (
MyException $e) {
// rethrow it
throw $e;
}
} catch (
Exception $e) {
var_dump($e->getMessage());
}
}
}
$foo = new Test;
$foo->testing();?>

The above example will output:

Example #6 Multi catch exception handling


<?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();?>

The above example will output:

Example #7 Omitting the caught variable

Only permitted in PHP 8.0.0 and later.


<?phpclass SpecificException extends Exception {}

function

test() {
throw new
SpecificException('Oopsie');
}

try {

test();
} catch (
SpecificException) {
print
"A SpecificException was thrown, but we don't care about the details.";
}
?>

Example #8 Throw as an expression

Only permitted in PHP 8.0.0 and later.


<?phpfunction test() {
do_something_risky() or throw new Exception('It did not work');
}

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[
}
?>


Генерация исключений

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

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

class Person
{
	private $name, $age;
	function __construct($name, $age)
	{
		$this->name = $name;
		$this->age = $age;
	}
	function printInfo()
	{
		echo "Name: $this->name<br>Age: $this->age";
	}
}
$tom = new Person("Tom", -105);
$tom->printInfo();

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

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

Например, изменим выше определенный код класса Person:

class Person
{
	private $name, $age;
	function __construct($name, $age)
	{
		if($age < 0)
		{
			throw new Exception("Недействительный возраст");
		}
		$this->name = $name;
		$this->age = $age;
	}
	function printInfo()
	{
		echo "Name: $this->name<br>Age: $this->age";
	}
}
$tom = new Person("Tom", -105);
$tom->printInfo();

Теперь если возраст отрицательный, то будет генерироваться исключение типа Exception.

throw new Exception("Недействительный возраст");

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

В итоге при выполнении строки

$tom = new Person("Tom", -105);

будет выполняться код

throw new Exception("Недействительный возраст");

И в итоге в браузере мы увидем информацию об ошибке:

Fatal error: Uncaught Exception: Недействительный возраст in D:localhosthello.php:17 Stack trace: #0 D:localhosthello.php(26): Person->__construct('Tom', -105) #1 {main} thrown in D:localhosthello.php on line 17

Поскольку вызов конструктора класса Person создает ситуацию, в которой потенциально может возникнуть исключение, то лучше вызов конструктора поместить
в конструкцию try..catch:

class Person
{
	private $name, $age;
	function __construct($name, $age)
	{
		$this->name = $name;
		if($age < 0)
		{
			throw new Exception("Недействительный возраст");
		}
		$this->age = $age;
	}
	function printInfo()
	{
		echo "Name: $this->name<br>Age: $this->age";
	}
}

try
{
	$tom = new Person("Tom", -105);
	$tom->printInfo();
}
catch(Exception $ex)
{
	echo $ex -> getMessage();
}

Вывод браузера:

Недействительный возраст

Создание классов исключений

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

class PersonInvalidAgeException extends Exception
{
	function __construct($age)
	{
		$this -> message = "Недействительный возраст: $age. Возраст должен быть в диапазоне от 0 до 120";
	}
}
class Person
{
	private $name, $age;
	function __construct($name, $age)
	{
		$this->name = $name;
		if($age < 0)
		{
			throw new PersonInvalidAgeException($age);
		}
		$this->age = $age;
	}
	function printInfo()
	{
		echo "Name: $this->name<br>Age: $this->age";
	}
}

try
{
	$tom = new Person("Tom", -105);
	$tom->printInfo();
}
catch(PersonInvalidAgeException $ex)
{
	echo $ex -> getMessage();
}

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

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

Недействительный возраст: -105. Возраст должен быть в диапазоне от 0 до 120

Содержание

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

Модель исключений (exceptions) в PHP 5 схожа с используемыми в других языках программирования.
Исключение можно сгенерировать (как говорят, «выбросить») при помощи оператора
throw, и можно перехватить (или, как говорят, «поймать»)
оператором catch. Код генерирующий исключение, должен
быть окружен блоком try, для того чтобы можно было
перехватить исключение. Каждый блок try
должен иметь как минимум один соответствующий ему блок catch или finally.

Генерируемый объект должен принадлежать классу Exception
или наследоваться от Exception. Попытка сгенерировать
исключение другого класса приведет к неисправимой ошибке.

catch

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

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

finally

В PHP 5.5 и более поздних версиях также можно использовать блок finally
после или вместо блока catch. Код в блоке
finally всегда будет выполняться после кода в блоках
try и catch, вне зависимости было ли
брошено исключение или нет, перед тем как продолжится нормальное выполнение кода.
whether an exception has been thrown, and before normal execution resumes.

Примеры

Пример #3 Выброс исключений


<?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 "Hello Worldn";
?>

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

0.2
Выброшено исключение: Деление на ноль.
Hello World

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


<?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 "Hello Worldn";
?>

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

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

Пример #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();?>

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

Вернуться к: Справочник языка

Если ты изучаешь ООП, то наверняка натыкался на понятие исключения, а может даже уже видел его где-то в коде. В этом уроке я постараюсь объяснить, что такое исключение в PHP и зачем они нужны. Расскажу когда, какое и как правильно применять то или иное исключение при разработке.

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

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

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

// Где-то (модель или сервис)
public function delete($id)
{
 $category = Category::find($id);
 // Если категория не найдена - кидаем исключение
 if (!$category) throw new Exception('Page Not Found!');
 // Если в категории есть посты - кидаем исключение
 if (count($category->posts) > 0) throw new Exception('Cannot delete category with posts!');
 // Если всё хорошо - продолжаем выполнение кода
 // Удаляем категорию
}


// В контроллере
public function deleteAction($id)
{
  try {
  // Если метод delete() из модели возвращает true 
    $model->delete($id);
  } catch (Exception $e) {
  	// Если false - ловим брошенное из модели исключение 
    echo $e->getMessage();
    // Или вывести в уведомление через сессию, например
    // Session::set('error', $e->getMessage());
  }
}

Согласитесь, удобно. Вместо того, чтобы просто возвращать false в случае, когда срабатывает условие if (count($category->products) > 0), лучше кинуть исключение и как-то оповестить пользователя о каких-либо возникших исключительных ситуациях. Если же мы просто вернём false, то мы сами со временем не сможем понять, что именно там случилось и почему этот метод не работает. Поэтому, я советую всегда пользоваться исключениями, но слишком не увлекаясь этим делом.

Класс Exception

Исключение (Exception) – это объект, являющийся экземпляром встроенного класса Exception. Этот объект создаётся для хранения информации о произошедшей ошибке и для вывода сообщений о ней.

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

  • getMessage() – возвращает строку, которая была передана конструктору и содержит сообщение об ошибке.
  • getCode() – возвращает код ошибки (тип int), который был передан конструктору.
  • getFile() – возвращает имя файла в котором было сгенерировано исключение.
  • getLine() – возвращает номер строки в которой было сгенерировано исключение.
  • getTrace() – возвращает многомерный массив, содержащий последовательность методов, вызов которых привёл к генерированию исключения. Так же содержит параметры, которые были переданы этим методам и номера строк, где осуществлялись вызовы.
  • getTraceAsString() – возвращает строковую версию данных, которые возвращает метод getTrace().
  • __toString() – магический метод, который вызывается, когда экземпляр класса Exception приводится к строке.

Генерация исключений

Для генерации исключения используется ключевое слово throw и экземпляр класса Exception. С английского throw переводится как «бросать», что очень точно описывает поведение этого оператора. Он генерирует (бросает) исключение в каком-либо методе (в котором может случиться нестандартная, исключительная ситуация) и останавливает дальнейшее выполнение кода, тем самым предоставляя возможность обработать это исключение в методе (в любом месте приложения), который будет вызывать данный метод с брошенным исключением.

// Класс User
class User
{
  private $name;

  public function setName($name)
  {
    if (!$name) throw new InvalidArgumentException('Имя не задано!');
    if (strlen($name) < 3) throw new LengthException('Имя должно быть больше 3-х символов!');
    $this->name = $name;
  }

  public function getName(): string
  {
    return $this->name;
  }

	// ...
}

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

И так, метод, который вызывает метод, в котором в свою очередь может быть брошено исключение, должен сам его обрабатывать. Обработка исключения производится при помощи операторов try - catch. Блок кода, который может поймать исключение, располагается после try. Блок кода, который обрабатывает исключение, располагается после оператора catch. В переводе с английского try означает «пытаться», что очень точно отражает суть этого оператора, ведь мы пытаемся выполнить блок кода после него, а если не получается то выполняется блок кода после catch. Catch переводится как «ловить». Он фактически «ловит» сгенерированное исключение. В примере ниже мы ловим исключение из метода setName() класса User из примера выше:

// Где-то ловим исключение и обрабатываем его
try {
  $user = new User();
  $user->setName('John');
  // Случится исключение InvalidArgumentException
	$user->setName('');
  // Случится исключение LengthException
  $user->setName('Jo');
  echo $user->getName();
} catch (Exception $e) {
    echo "Message: {$e->getMessage()}<br>
    Code: {$e->getCode()}<br>
    File: {$e->getFile()}<br>
    Line: {$e->getLine()}";
}

Ловим исключение в блоке try:

try {
  // ...

  $config = "config.php";
  if (!file_exists($config)) {
    throw new Exception("Configuration file not found.");
  }

  // ...
} catch (Exception $e) {
  echo $e->getMessage();
  die();
}

Но так делать не рекомендуется (try/catch и throw на одном уровне). В этом случае проще написать if!

Оператор catch внешне напоминает объявление метода с уточнением типа его аргумента. Когда генерируется исключение, управление передаётся оператору catch, при этом в качестве аргумента ему передаётся объект типа Exception.

Создание подклассов класса Exception

От встроенного класса Exception можно унаследовать классы для своих собственных исключений. Делать это можно для того чтобы расширить его функциональность или создать свой собственный тип ошибок. Создание своих собственных типов ошибок нужно для того, чтобы была возможность по-разному обрабатывать разные исключения. Для этого существует возможность писать несколько операторов catch. Какой именно из них вызовется, будет зависеть от типа сгенерированного исключения, от типа, который уточнён в аргументе и от порядка, в котором расположены операторы catch.

Пример собственного класса исключения:

<?php
/**
 * Определим свой класс исключения
 */
class MyException extends Exception
{
  // Переопределим исключение так, что параметр message станет обязательным
  public function __construct($message, $code = 0, Exception $previous = null) {
    // некоторый код 

    // убедитесь, что все передаваемые параметры верны
    parent::__construct($message, $code, $previous);
  }

  // Переопределим строковое представление объекта.
  public function __toString() {
    return __CLASS__ . ": [{$this->code}]: {$this->message}n";
  }

  public function customFunction() {
    echo "Мы можем определять новые методы в наследуемом классеn";
  }
}

Полная иерархия исключений в PHP

Throwable (интерфейс)
├── Exception (реализует Throwable)
│   ├── LogicException (расширяет Exception)
│   │   ├── BadFunctionCallException (расширяет LogicException)
│   │   │   └── BadMethodCallException (расширяет BadFunctionCallException)
│   │   ├── DomainException (расширяет LogicException)
│   │   ├── InvalidArgumentException (расширяет LogicException)
│   │   ├── LengthException (расширяет LogicException)
│   │   └── OutOfRangeException (расширяет LogicException)
│   └── RuntimeException (расширяет Exception)
│       ├── OutOfBoundsException (расширяет RuntimeException)
│       ├── OverflowException (расширяет RuntimeException)
│       ├── RangeException (расширяет RuntimeException)
│       ├── UnderflowException (расширяет RuntimeException)
│       └── UnexpectedValueException (расширяет RuntimeException)
└── Error (реализует Throwable)
    ├── AssertionError (расширяет Error)
    ├── ParseError (расширяет Error)
    └── TypeError (расширяет Error)	

Throwable

Throwable — это даже не исключение, а интерфейс, который реализуют все остальные рассматриваемые классы. Добавлен в PHP7.

Exception

Базовый класс для исключений. Стандартная библиотека SPL вводит две группы исключений, два надкласса: для исключений в логике: LogicException и исключений времени исполнении RuntimeException.

LogicException

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

BadFunctionCallException

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

BadMethodCallException

Подкласс BadFunctionCallException. Аналогично ему используется для методов, которые не существуют или которым передано неверное число параметров. Всегда используйте внутри __call(), в основном для этого оно и применяется.

Пример использования этих двух исключений:

// Для метода в __call 
class Foo 
{     
  public function __call($method, $args)     
  {         
   switch ($method) {
        case 'someExistentClass': /* do something positive... */ break;
        default:
        	throw new BadMethodCallException('Метод ' . $method . ' не может быть вызван');
        }
    }   
}
   
// процедурный подход function 
foo($arg1, $arg2) 
{
   $func = 'do' . $arg2;
   if (!is_callable($func)) {         
    throw new BadFunctionCallException('Функция ' . $func . ' не может быть вызвана');     
  } 
}

DomainException

Если в коде подразумеваются некие ограничения для значений, то это исключение можно вызывать, когда значение выходит за эти ограничения. Например, у вас дни недели обозначаются числами от 1 до 7, а ваш метод получает внезапно на вход 0 или 9, или, скажем, вы ожидаете число, обозначающее количество зрителей в зале, а получаете отрицательное значени. В таких случаях и вызывается DomainException. Также можно использовать для разных проверок параметров, когда параметры нужных типов, но при этом не проходят проверку на значение. Например:

if ($a > 5)
    throw new DomainException ("Переменная a должна быть меньше 5");

InvalidArgumentException

Вызываем, когда ожидаемые аргументы в функции/методе некорректно сформированы. Например, ожидается целое число, а на входе строка или ожидается GET, а пришел POST и т.п.

public function foo($number) {
  if(!is_numeric($number)) {
    throw new InvalidArgumentException('На входе ожидалось целое число!');
  }
}

LengthException

Вызываем, если длина чего-то слишком велика или мала. Например, имя файла слишком короткое или длина строки слишком большая.

RuntimeException

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

OutOfBoundsException

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

Пример использования в реализации ArrayAccess:

public function offsetGet($offset) {
  if(!isset($this->objects[$offset])) {
    throw new OutOfBoundsException("Смещение '$offset' вышло из заданного диапазона");
  }

  return $this->objects[$offset];
}

OutOfRangeException

Используется, когда встречаем некорректный индекс, но на этот раз ошибка должна быть обнаружена ещё до прогона кода, например, если мы пытаемся адресовать элемент массива, который в принципе не поддерживается. То есть если функция, возвращающая день недели по его индексу от 1 до 7, получает внезапно 9, то это DomainException — ошибка логики, а если у нас есть массив с днями недели с индексами от 1 до 7, а мы пытаемся обратиться к элементу с индексом 9, то это уже OutOfRangeException.

OverflowException

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

UnderflowException

Обратная OverflowException ситуация, когда, например, класс-контейнер имеет недостаточно элементов для осуществления операции. Например, когда он пуст, а вы пытаетесь удалить элемент.

RangeException

Вызывается, когда значение выходит за границы некоего диапазона. Похоже на DomainException, но используется при возврате из функции, а не при входе. Если мы не можем вернуть легитимное значение, мы выбрасываем это исключение. То есть, к примеру, функция у вас принимает целочисленный индекс и использует другую функцию, чтоб получить некое значение по этой сущности. Та функция вернула null, но ваша функция не имеет права возвращать Null. В таком случае можно применить это исключение. То есть между ними примерно такая же разница, как между OutOfBoundsException и OutOfRangeException.

UnexpectedValueException

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

Важно, что, в отличие от InvalidArgumentException, здесь мы имеем дело, в основном, с возвращаемыми значениями. Часто мы заранее не можем быть уверены в том, что придет в ответе от функции (особенно сторонней). Скажем, мы используем некую стороннюю функцию, использующую API ВКонтакте, и возвращющую количество постов для пользователя. Она всегда возвращала целое неотрицательное число, и вдруг неожиданно возвращает отрицательное число. Это не соответствует документации. Соответственно, чтобы подстраховаться от таких ситуаций, мы можем проверять результат такого вызова и, если он отличается от ожидаемого, выбрасывать UnexpectedValueException.

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

const TYPE_FOO = 'foo';
const TYPE_BAR = 'bar';

public function doSomething($y) {
  $x = ModuleUsingSomeExternalAPI::getValueOfX($y);
  if($x != self::TYPE_FOO || $x != self::TYPE_BAR) {
    throw new UnexpectedValueException('Параметр должен быть в виде TYPE_* констант');
  }
}

Error

Добавлено в PHP7 для обработки фатальных ошибок. То есть многие из ошибок, которые раньше приводили к Fatal Error, сейчас могут обрабатываться в блоках try/catch. Эти ошибки вызываются самим PHP, нет нужды их вызывать, как Exception. Класс Error имеет три подкласса:

AssertionError

Вызывается, когда условие, заданное методом assert(), не выполняется.

ParseError

Для ошибок парсинга, когда подключаемый по include/require код вызывает ошибку синтаксиса, ошибок функции eval() и т.п.

try {
   require 'file-with-syntax-error.php';
} catch (ParseError $e) {
   // обработка ошибки
}

TypeError

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

if (!is_string($name)) throw new TypeError('Имя должно быть стройкой!');

Учебный пример, в котором есть примеры использования всех классов исключений:

class Example
{
  protected $author;  
  protected $month;  
  protected $goals = [];
  
  public function exceptions(int $a, int $b): int
  {
    $valid_a = [7, 8, 9];
    if (!is_int($a)) {
      throw new InvalidArgumentException("a должно быть целочисленным!");
    }
    if ($a > 5 || !in_array($a, $valid_a, true)) {
      throw new DomainException("a не может быть больше 5");
    }
    
    $c = $this->getByIndex($a);
    if (!is_int($c)) {
      throw new RangeException("c посчитался неправильно!");
    } else {
      return $c;
    }      
  }
  
  private function getByIndex($a)
  {
    return ($a < 100) ? $a + 1 : null;
  }
  
  public function deleteNextGoal()
  {
    if (empty($this->goals)) {
      throw new UnderflowException("Нет цели, чтобы удалить!");
    } elseif (count($this->goals) > 100000) {
      throw new OverflowException("Система не может оперировать больше, чем 100000 целями одновременно!");
    } else {
      array_pop($this->goals);
    }
  }
  
  public function getGoalByIndex($i)
  {
    if (!isset ($this->goals[$i])) {
      throw new OutOfBoundsException("Нет цели с индексом $i"); // легитимные значения известны только во время выполнения
    } else {
      return $this->goals[$i];
    }
  }
  
  public function setPublicationMonth(int $month)
  {
    if ($month < 1 || $month > 12) {
      throw new OutOfRangeException("Месяц должен быть от 1 до 12!"); // легитимные значения известны заранее
    }
    $this->month = $month;
  }
  
  public function setAuthor($author)
  {
    if (mb_convert_case($author, MB_CASE_UPPER) !== $author) {
      throw new InvalidArgumentException("Все буквы имени автора должны быть заглавными");
    } else {
      if (mb_strlen($author) > 255) {
        throw new LengthException("Поле автор не должно быть больше 255 сиволов!");
      } else {
        $this->author = $author;
      }
    }
  }
  
  public function __call(string $name, array $args)
  {
    throw new BadMethodCallException("Метод Example>$name() не существует");
  }
}

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

Документация по исключениям в PHP здесь .

Ещё почитать на гитхабе .

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

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

Я рад бы написать что “эта статья предназначена для новичков”, но это не так. Большинство php-разработчиков, имея опыт 3, 5 и даже 7 лет, абсолютно не понимают как правильно использовать эксепшены. Нет, они прекрасно знают о их существовании, о том что их можно создавать, обрабатывать, и т.п., но они не осознают их удобность, логичность, и не воспринимают их как абсолютно нормальный элемент разработки.

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

Почему мы не умеем пользоваться эксепшенами:

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

PHP — это чрезмерно любящая мать. И при отсутствии строгого отца (например, Java) или самодисциплины, разработчик вырастет эгоистом, которому плевать на все правила, стандарты и лучшие практики. И вроде бы E_NOTICE пора включать, а он все на мать надеется. Которая, между прочим, стареет — ей уже E_STRICT c E_DEPRICATED нужны, а сынуля все на шее висит.

Виноват ли PHP — предмет дискуссий, но то, что с самого начала PHP не приучает нас к эксепшенам — это факт: его стандартные функции не создают эксепшены. Они либо возвращают false, намекая что что-то не так, или записывают куда-то код ошибки, который не всегда додумаешься проверить. Или впадают в другую крайность — Fatal Error.

И пока наш начинающий разработчик пытается написать свою первую быдло-cms, он ни разу не встретиться с механизмом эксепшенов. Вместо этого, он придумает несколько способов обработки ошибок. Я думаю, все понимают о чем я — эти методы, возвращающие разные типы (например, объект при успешном выполнении, а при неудаче — строка с ошибкой), или запись ошибки в какую-либо переменную/свойство, и всегда — куча проверок чтоб передать ошибку вверх по стеку вызовов.

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

И тогда ничего не произойдет. Ровном счетом ничего. У него уже сформировались отточенные месяцами/годами способы обработки ошибок — он продолжит использовать их. Вызванный кем-то (сторонней библиотекой) эксепшн будет восприниматься как определенный вид Fatal Error. Да, гораздо более детальный, да подробно логируется, да Yii покажет красивую страничку, но не более.

Затем он научиться отлавливать и обрабатывать их. И на этом его знакомство c эксепшенами закончиться. Ведь надо работать, а не учиться: знаний ему и так хватает (сарказм)!

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

Преимущества эксепшенов

На самом деле использование эксепшенов — крайне лаконичное и удобное решение создания и обработки ошибок. Приведу наиболее значимые преимущества:

Контекстная логика

Прежде всего, хотелось бы показать что эксепшн — это не всегда только ошибка (как обычно ее воспринимают разработчики). Иногда он может быть частью логики.

Например, есть у нас функция чтения JSON объекта из файла:

/**
 * Читает объект из JSON файла
 * @param string $file
 * @throws FileNotFoundException    файл не найден
 * @throws JsonParseException       не правильный формат json
 * @return mixed
 */
public function readJsonFile($file)
{
  ...
}

Допустим мы пытаемся прочитать какие-то ранее загруженные данные. При такой операции эксепшн FileNotFoundException не является ошибкой и вполне допустим: возможно, мы ни разу не загружали данные, поэтому файла и нет. А вот JsonParseException — это уже признак ошибки, ибо данные были заргужены, обработаны, сохранены в файл, но почему-то сохранились не правильно.

Совсем другое дело, когда мы пытаемся прочитать файл, который должен быть всегда: при такой операции FileNotFoundException так же является сигналом ошибки.

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

Упрощение логики и архитектуры приложения

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

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

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

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

Вот пример информативного интерфейса, который дополнен знаниями об эксепшенах:

interface KladrService
{
	/**
	 * Определяет код КЛАДР по адресу
	 * @param Address $address
	 * @return string код для адреса
	 * @throws AddressNotFoundException     адрес не найден в базе адресов
	 * @throws UnresoledAddressException    адрес найден, но для него не существует код КЛАДР
	 */
	public function resolveCode(Address $address);

	/**
	 * Определяет адрес по коду КЛАДР
	 * @param string $code
	 * @return Address
	 * @throws CodeNotFoundException    не найлен код КЛАДР
	 */
	public function resolveAddress($code);
}

Следует упомянуть что разрабатывая классы эксепшенов мы должны следовать принципу информативного интерфейса. Грубо говоря — учитывать их логический смысл, а не физический. Например, если адреса у нас храняться в файлах, то отсутствие файла адреса вызовет FileNotFoundException. Мы же должны перехватить его и вызвать более осмысленный AddressNotFoundException.

Использование объектов

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

if(Yii::app()->kladr->getLastError() == ‘Не найден адрес’){
	….
}

try{
	...
}
catch(AddressNotFoundException $e){
	...
}

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

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

/**
 * Адрес не найден в базе адресов
 */
class AddressNotFoundException extends Exception
{
	/**
	 * Не найденный адрес
	 * @var Address
	 */
	private $address;

	/**
	 * @param Address $address
	 */
	public function __construct(Address $address)
	{
		Exception::__construct('Не найден адрес '.$address->oneLine);
		$this->address = $address;
	}
	/**
	 * @return Address
	 */
	public function getAddress()
	{
		return $this->address;
	}
}

Как видим — эксепшн содержит адрес, который не удалось найти. Обработчик может его получить и выполнить на основании его какую-то свою логику.

Третье преимущество — это, собственно, все преимущества ООП. Хотя эксепшены, как правило, простые объекты, поэтому возможности ООП мало используются, но используются.

Например, у меня в приложении порядка 70 классов эксепшенов. Из них несколько — базовых — по одному классу на модуль. Все остальные — наследуются от базового класса своего модуля. Сделано это для удобства анализа логов.

Так же я использую несколько ИНТЕРФЕЙС-МАРКЕРОВ:

  • UnloggedInterface: По умолчанию у меня логируются все необработанные ошибки. Этим интерфейсом я помечаю эксепшены, которые не надо логировать вообще.
  • PreloggedInterface: Этим интерфейсом я помечаю эксепшены, которые необходимо логировать в любом случае: неважно, обработаны они или нет.
  • OutableInterface: Этот интерфейс помечает эксепшены, текст которых можно выдавать пользователю: далеко не каждый эксепшн можно вывести пользователю. Например, можно вывести эксепшн с текстом “Страница не найдена” — это нормально. Но нельзя выводить эксепшн с текстом “Не удалось подключиться к Mysql используя логин root и пароль 123”. OutableInterface помечает эксепшены которые выводить можно (таких у меня меньшинство). В остальных ситуация выводиться что то типа “Сервис не доступен”.

Обработчик по умолчанию, логирование

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

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

Откат изменений: так как операция не выполнена до конца, необходимо откатить все сделанные изменения. В противном случае мы испортим данные. Например, можно в CController::beforeAction() открыть транзакцию, в CController::afterAction() коммитить, а в случае ошибки сделать роллбэк в обработчике по умолчанию.

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

public function addPosition(Position $position)
{
  try
  {
    ... выполнение операции ...	
  }
  catch(Exception $e)
  {
    ... откат изменений ...
    
    throw $e;   // Заново бросаем тот же эксепшн
  }
}

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

Логирование: так же обработчик по умолчанию позволяет нам выполнить какое-то кастомное логирование. Например, в моем приложении я все складываю в базу и использую собственное средство для анализа. На работе мы используем getsentry.com/welcome. В любом случае, эксепшн, дошедший до обработчика по умолчанию — скорее всего непредусмотренный эксепшн, и его необходимо логировать. Следует отметить, что в класс эксепшена можно добавить различную информацию, которую необходимо логировать для большего понимания причины возникновения ошибки.

Невозможность не заметить и перепутать

Огромным плюсом эксепшена является его однозначность: его не возможно не заметить и не возможно с чем-то спутать.

Из первого следует что мы всегда будем осведомлены о возникшей ошибке. И это замечательно — всегда лучше знать о проблеме, чем не знать.

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

$result = $this->doAnything(); // null если не нашла нужный объект и false в случае ошибки

// Не заметит ошибки
if($result){ ... }

// Не заметит ошибки
if($result == null){ ... }

// Не заметит ошибки
if(empty($result)){ ... }

// Не заметит ошибки
if($result = null){ ... }

Эксепшн же невозможно пропустить.

Прекращение ошибочной операции

Но самое главное, и самое важное, что делает эксепшн — это прекращает дальнейшее выполнение операции. Операции, которая уже пошла не так. И, следовательно, результат которой непредсказуем.

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

$this->doOperation();
if($this->getLastError() !== null)
{
    echo $this->getLastError(); 
    die;
}

Это требует определенной дисциплины от разработчиков. А далеко не все дисциплинированны. Далеко не все вообще знают что у вашего объекта есть метод getLastError(). Далеко не все понимают, почему вообще так важно проверит что все идет как надо, а если нет — откатить изменения и прекратить выполнение.

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

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

Когда следует вызывать эксепшены:

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

Встает вопрос: в каких ситуациях стоит вызывать эксепшн?

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

Посмотрим на простейший экшн добавления записи:

/**
 * Создает пост
 */
public function actionCreate()
{
  $post = Yii::app()->request->loadModel(new Post());
  if($post->save())
  {
    $this->outSuccess($post);
  }
  else
  {
    $this->outErrors($post);
  }
}

Когда мы введем некорректные данные поста эксепшн не вызывается. И это вполне соответствует формуле:

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

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

/**
 * Отменяет заказа.
 * Отмена производиться путем смены статуса на STATUS_CANCEL.
 * @throws Exception
 */
public function cancel()
{
  // Проверим, находиться ли STATUS_CANCEL в разрешенных
  if(!$this->isAllowedStatus(self::STATUS_CANCEL))
  {
    throw new Exception('Cancel status not allowed');
  }

  // Сообственно смена статуса
  $this->status = self::STATUS_CANCEL;
  $isSaved = $this->save();

  // Проверка на то что все успешно сохранилось и что после сохранения статус остался STATUS_CANCEL
  if(!$isSaved|| $this->status !== self::STATUS_CANCEL)
  {
    throw new Exception('Bad logic in order cancel');
  }
}

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

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

Далее идет выполнение операции и сохранение изменений.

Затем идет поствалидация — мы проверяем, действительно ли все сохранилось, и действительно ли статус изменился. На первый взгляд это может показаться бессмысленным, но: заказ вполне мог не сохранится (например, не прошел валидацию), а статус вполне мог быть изменен (например, кто-то набыдлокодил в CActiveRecord::beforeSave). Поэтому эти действия необходимы, и, опять-таки, если что-то пошло не так — бросаем эксепшн, так как в пределах данного метода мы не знаем как обрабатывать эти ошибки.

Эксепшн vs возврат null

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

Тут следует обратить внимание на обязанности метода. Например, СActiveRecord::find() не бросает эксепшн, и это логично — уровень его “знаний” не содержит информации о том, является ли ошибкой отсутствие результата. Другое дело, например, метод KladrService::resolveAddress() который в любом случае обязан вернуть объект адреса (иначе либо код неправильный, либо база не актуальная). В таком случае нужно бросать эксепшн, ибо отсутствие результата — это ошибка.

В целом же, описанная формула идеально определяет места, где необходимо бросать эксепшены. Но особо хотелось бы выделить 2 категории эксепшенов, которых нужно делать как можно больше:

Технические эксепшены

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

Вот несколько примеров:

// В нескольких if
if($condition1)
{
	$this->do1();
}
elseif($condition2)
{
	$this->do2();
}

...

else
{
	// Когда должен сработать один из блоков if, но не сработал - бросаем эксепшн
	throw new BadLogicException;
}

// То же самое в swith
switch($c)
{
	case 'one':
		return 1;

	case 'two'
		return 2;

		...

	default:
		// Когда должен сработать один из блоков case, но не сработал - бросаем эксепшн
		throw new BadLogicException;
}

// При сохранении связанных моделей
if($model1->isNewRecord)
{
	// Если первая модель не сохранена, у нее нет id, то строка $model2->parent_id = $model1->id
	// сделает битые данные, поэтому необходимо проверять
	throw new BadLogicException;
}

$model2->parent_id = $model1->id;

// Просто сохранении - очень часто разраотчики используют save и не проверяют результат
if(!$model->save())
{
	throw new BadLogicException;
}

/**
 * Cкоуп по id пользователя
 * @param int $userId
 * @return $this
 */
public function byUserId($userId)
{
	if(!$userId)
	{
		// Если не вызывать этот эксепшн, то при пустом userId скоуп вообще не будет применен
		throw new InvalidArgumentException;
	}

	$this->dbCriteria->compare('userId', $userId);
	return $this;
}

Технические эксепшены помогут не допустить или отловить, имхо, большую часть багов в любом проекте. И неоспоримым плюсом их использования является отсутствие необходимости понимать предметную область: единственное что требуется — это дисциплина разработчика. Я призываю не лениться и вставлять такие проверки повсеместно.

Эксепшены утверждений

Эксепшены утверждений (по мотивам DDD) вызываются когда мы обнаруживаем что нарушается какая-либо бизнес-логика. Безусловно, они тесно связанна с знаниями предметной области.

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

Например, есть метод добавления позиции в заказ:

/**
 * Добовляет позицию в заказ
 * @param Position $position
 * @throws Exception
 */
public function addPosition(Position $position)
{
  $this->positions[] = $position;

  ... перерасчет стоимость позиций, доставки, скидок, итоговой стоимсоти ...

// проверям корректность рассчета
  if($this->totalCost != $this->positionsCost + $this->deliveryCost - $this->totalDiscounts)
  {
    throw new Exception('Cost recalculation error');
  }

  ... Обновление параметров доставки ...

// проверям можем ли мы доставить заказа с новой позицеей
  if(!Yii::app()->deliveryService->canDelivery($this))
  {
    throw new Exception('Cant delivery with new position')
  }

… прочие действия ...
}

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

Здесь можно подискутировать на тему необходимости подобных эксепшенов:
Например, можно написать тесты на методы перерасчета стоимости заказа, и проверка в теле метода — не более чем дублирование теста. Можно проверять возможность доставки заказа с новой позицией до добавления позиции (чтоб предупредить об этом пользователя, как минимум)

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

Поэтому в критичных местах такие эксепшены нужны однозначно.

Изменение логики для избегания эксепшна

Как я уже говорил, PHP разработчики боятся эксепшенов. Они боятся их появления, и боятся бросать их самостоятельно.

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

Вот пример: необходимо просто отобразить страницу по id (чтоб вы понимали — это реальный код из известного проекта)

/**
 * Отображает страницу по id
 * @param int $id
 */
public function actionView($id = 1)
{
  $page = Page::model()->findByPk($id) ?: Page::model()->find();
  $this->render('view', ['page' => $page]);
}

Несмотря на простейшую и понятную задачу — здесь совершенно дикая логика.
Мало того, что она может показать пользователю совершенно не то что надо, так она еще и маскирует наши баги:

  • если id не задан — берется id = 1. Проблема в том, что когда id не задан — это уже баг, ибо где-то у нас не правильно формируются ссылки.
  • Если страница не найдена — значит где-то у нас ссылка на несуществующую страницу. Это тоже, скорее всего, баг.

Такое поведение не приносит пользы ни пользователю, ни разработчикам. Мотивация такой реализации — показать хоть что-то, ибо 404 эксепшн — плохо.

Еще один пример:

/**
 * Выдает код кладра города
 * @param mixed $region
 * @param mixed $city
 * @return string
 */
public function getCityKladrCode($region, $city)
{
  if($сode = ... получение кода для города... )
  {
    return $сode;
  }

  return ... получение кода для региона ...
}

Тоже из реального проекта, и мотивация такая-же: вернуть хоть что-то, но не вызывать эксепшн, несмотря на то, что метод явно должен возвращать код города, а не региона.

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

Мое мнение — это недопустимо. Просто когда ты работаешь с большими деньгами (а я с ними работал довольно долго), вырабатывается определенные правила, и одно из них — прерывать операцию в случае любого подозрения на ошибку. Транзакция на 10 млн баксов: согласитесь, ее лучше отменить, чем перечислить деньги не тому человеку.

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

Собачки

Я почему-то думал что собачками уже никто не пользуется. Но недавно столкнулся с коллективом разработчиков, которые используют их повсеместно вместо проверки isset, поэтому решил написать и про них.

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

@$policy->owner->address->locality;

против

isset($policy->owner->address) ? $policy->owner->address->locality : null;

Действительно, выглядит намного короче, и на первый взгляд результат такой же. Но! опасно забывать что собачка — оператор игнорирования сообщений об ошибках. И @$policy->owner->address->locality вернет null не потому-что проверит существование цепочки объектов, а потому-что просто проигнорирует возникшую ошибку. А это совершенно разные вещи.

Проблем в том, что помимо игнорирования ошибки Trying to get property of non-object (которое и делает поведение собачки похожим на isset), игнорируются все другие возможные ошибки.

PHP — это магический язык! При наличии всех этих магических методов (__get, __set, __call, __callStatic, __invoke и пр.) мы не всегда можем сразу понять что происходит на самом деле.

Например, еще раз взглянем на строку $policy->owner->address->locality. На первый взгляд — цепочка объектов, если присмотреться пристально — вполне может быть и так:

  • policy — модель CActiveRecord
  • owner — релейшен
  • address — геттер, который, например, обращается к какому-либо стороннему сервису
  • locality — аттрибут у

То есть простой строкой $policy->owner->address->locality мы на самом деле запускаем выполнение тысяч строк кода. И собачка перед это строкой скрывает ошибки в любой из этих строк.

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

Послесловие

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

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

Но попробуйте собрать конструктор без инструкции… Эта мысль похожа на бред. Тем не менее, программисты без всех этих знаний прекрасно работают. Годами. И им это не кажется бредом — они даже не понимают, что что-то делают не так. Вместо этого они жалуются что им дали слишком мало времени.

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

Так что всем, кто прочел этот пост и подумал “что за бред”, “я все это знаю, но применять лень”, или “будет сосунок мне указывать” — я желаю совершить баг. Баг, за который оштрафуют или уволят. И тогда вы, возможно, вспомните этот пост, и задумаетесь: “возможно я и в правду что-то делаю не так”?

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

Всем добра )

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

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

  • Яндекс еда ошибка привязки карты
  • Php soap ошибка
  • Php выкинуть ошибку
  • Php require once ошибка
  • Php вызов ошибки

  • 0 0 голоса
    Рейтинг статьи
    Подписаться
    Уведомить о
    guest

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