Laravel обработчик ошибок

  • Введение
  • Конфигурирование
  • Обработчик исключений

    • Отчет об исключениях
    • Игнорирование исключений по типу
    • Отображение исключений
    • Отчетные и отображаемые исключения
    • Сопоставление исключений по типу
  • HTTP-исключения

    • Пользовательские страницы ошибок HTTP

Введение

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

Конфигурирование

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

Во время локальной разработки вы должны установить для переменной окружения APP_DEBUG значение true. Во время эксплуатации приложения это значение всегда должно быть false. Если в рабочем окружении будет установлено значение true, вы рискуете раскрыть конфиденциальные значения конфигурации конечным пользователям вашего приложения.

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

Отчет об исключениях

Все исключения обрабатываются классом AppExceptionsHandler. Этот класс содержит метод register, в котором вы можете зарегистрировать свои отчеты об исключениях и замыкания рендеринга. Мы подробно рассмотрим каждую из этих концепций. Отчеты об исключениях используются для регистрации исключений или отправки их во внешнюю службу, например Flare, Bugsnag или Sentry. По умолчанию исключения будут регистрироваться в соответствии с вашей конфигурацией логирования. Однако вы можете регистрировать исключения как хотите.

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

use AppExceptionsInvalidOrderException;

/**
 * Зарегистрировать замыкания, обрабатывающие исключения приложения.
 *
 * @return void
 */
public function register()
{
    $this->reportable(function (InvalidOrderException $e) {
        //
    });
}

Когда вы регистрируете собственные замыкания для создания отчетов об исключениях, используя метод reportable, Laravel по-прежнему регистрирует исключение, используя конфигурацию логирования по умолчанию для приложения. Если вы хотите остановить распространение исключения в стек журналов по умолчанию, вы можете использовать метод stop при определении замыкания отчета или вернуть false из замыкания:

$this->reportable(function (InvalidOrderException $e) {
    //
})->stop();

$this->reportable(function (InvalidOrderException $e) {
    return false;
});

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

Глобальное содержимое журнала

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

/**
 * Получить переменные контекста по умолчанию для ведения журнала.
 *
 * @return array
 */
protected function context()
{
    return array_merge(parent::context(), [
        'foo' => 'bar',
    ]);
}

Контекст журнала исключений

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

<?php

namespace AppExceptions;

use Exception;

class InvalidOrderException extends Exception
{
    // ...

    /**
     * Получить контекстную информацию исключения.
     *
     * @return array
     */
    public function context()
    {
        return ['order_id' => $this->orderId];
    }
}

Помощник report

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

public function isValid($value)
{
    try {
        // Проверка `$value` ...
    } catch (Throwable $e) {
        report($e);

        return false;
    }
}

Игнорирование исключений по типу

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

use AppExceptionsInvalidOrderException;

/**
 * Список типов исключений, о которых не следует сообщать.
 *
 * @var array
 */
protected $dontReport = [
    InvalidOrderException::class,
];

За кулисами Laravel уже игнорирует для вас некоторые типы ошибок, такие как исключения, возникающие из-за ошибок 404 HTTP «не найдено» или 419 HTTP-ответ, сгенерированный при недопустимом CSRF-токене.

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

По умолчанию обработчик исключений Laravel будет преобразовывать исключения в HTTP-ответ за вас. Однако вы можете зарегистрировать свое замыкание для отображения исключений конкретного типа. Вы можете сделать это с помощью метода renderable обработчика исключений.

Замыкание, переданное методу renderable, должно вернуть экземпляр IlluminateHttpResponse, который может быть сгенерирован с помощью функции response. Laravel определит, какой тип исключения отображает замыкание с помощью типизации аргументов:

use AppExceptionsInvalidOrderException;

/**
 * Зарегистрировать замыкания, обрабатывающие исключения приложения.
 *
 * @return void
 */
public function register()
{
    $this->renderable(function (InvalidOrderException $e, $request) {
        return response()->view('errors.invalid-order', [], 500);
    });
}

Вы также можете использовать метод renderable чтобы переопределить отображение для встроенных исключений Laravel или Symfony, таких, как NotFoundHttpException. Если замыкание, переданное методу renderable не возвращает значения, будет использоваться отрисовка исключений Laravel по умолчанию:

use SymfonyComponentHttpKernelExceptionNotFoundHttpException;

/**
 * Зарегистрировать замыкания, обрабатывающие исключения приложения.
 *
 * @return void
 */
public function register()
{
    $this->renderable(function (NotFoundHttpException $e, $request) {
        if ($request->is('api/*')) {
            return response()->json([
                'message' => 'Record not found.'
            ], 404);
        }
    });
}

Отчетные и отображаемые исключения

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

<?php

namespace AppExceptions;

use Exception;

class InvalidOrderException extends Exception
{
    /**
     * Отчитаться об исключении.
     *
     * @return bool|null
     */
    public function report()
    {
        //
    }

    /**
     * Преобразовать исключение в HTTP-ответ.
     *
     * @param  IlluminateHttpRequest  $request
     * @return IlluminateHttpResponse
     */
    public function render($request)
    {
        return response(...);
    }
}

Если ваше исключение расширяет исключение, которое уже доступно для визуализации, например встроенное исключение Laravel или Symfony, вы можете вернуть false из метода render исключения, чтобы отобразить HTTP-ответ исключения по умолчанию:

/**
 * Преобразовать исключение в HTTP-ответ.
 *
 * @param  IlluminateHttpRequest  $request
 * @return IlluminateHttpResponse
 */
public function render($request)
{
    // Определить, требуется ли для исключения пользовательское отображение...

    return false;
}

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

/**
 * Сообщить об исключении.
 *
 * @return bool|null
 */
public function report()
{
    // Определить, требуется ли для исключения пользовательская отчетность ...

    return false;
}

Вы можете указать любые требуемые зависимости метода report, и они будут автоматически внедрены в метод контейнером служб Laravel.

Сопоставление исключений по типу

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

К счастью, Laravel позволяет вам удобно сопоставлять эти исключения с другими типами исключений, которыми вы управляете в своем приложении. Для этого вызовите метод map из метода register вашего обработчика исключений :

use LeagueFlysystemException;
use AppExceptionsFilesystemException;

/**
 * Register the exception handling callbacks for the application.
 *
 * @return void
 */
public function register()
{
    $this->map(Exception::class, FilesystemException::class);
}

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

use LeagueFlysystemException;
use AppExceptionsFilesystemException;

$this->map(fn (Exception $e) => new FilesystemException($e));

HTTP-исключения

Некоторые исключения описывают коды HTTP-ошибок с сервера. Например, это может быть ошибка «страница не найдена» (404), «неавторизованный доступ» (401) или даже ошибка 500, сгенерированная разработчиком. Чтобы создать такой ответ из любой точки вашего приложения, вы можете использовать глобальный помощник abort:

abort(404);

Пользовательские страницы ошибок HTTP

Laravel позволяет легко отображать пользовательские страницы ошибок для различных кодов состояния HTTP. Например, если вы хотите настроить страницу ошибок для кодов HTTP-состояния 404, создайте файл resources/views/errors/404.blade.php. Это представление будет отображено для всех ошибок 404, сгенерированных вашим приложением. Шаблоны в этом каталоге должны быть названы в соответствии с кодом состояния HTTP, которому они соответствуют. Экземпляр SymfonyComponentHttpKernelExceptionHttpException, вызванный функцией abort, будет передан в шаблон как переменная $exception:

<h2>{{ $exception->getMessage() }}</h2>

Вы можете опубликовать стандартные шаблоны страниц ошибок Laravel с помощью команды vendor:publish Artisan. После публикации шаблонов вы можете настроить их по своему вкусу:

php artisan vendor:publish --tag=laravel-errors
Источник

Version


Error Handling

  • Introduction
  • Configuration
  • The Exception Handler

    • Reporting Exceptions
    • Exception Log Levels
    • Ignoring Exceptions By Type
    • Rendering Exceptions
    • Reportable & Renderable Exceptions
  • HTTP Exceptions

    • Custom HTTP Error Pages

Introduction

When you start a new Laravel project, error and exception handling is already configured for you. The AppExceptionsHandler class is where all exceptions thrown by your application are logged and then rendered to the user. We’ll dive deeper into this class throughout this documentation.

Configuration

The debug option in your config/app.php configuration file determines how much information about an error is actually displayed to the user. By default, this option is set to respect the value of the APP_DEBUG environment variable, which is stored in your .env file.

During local development, you should set the APP_DEBUG environment variable to true. In your production environment, this value should always be false. If the value is set to true in production, you risk exposing sensitive configuration values to your application’s end users.

The Exception Handler

Reporting Exceptions

All exceptions are handled by the AppExceptionsHandler class. This class contains a register method where you may register custom exception reporting and rendering callbacks. We’ll examine each of these concepts in detail. Exception reporting is used to log exceptions or send them to an external service like Flare, Bugsnag, or Sentry. By default, exceptions will be logged based on your logging configuration. However, you are free to log exceptions however you wish.

If you need to report different types of exceptions in different ways, you may use the reportable method to register a closure that should be executed when an exception of a given type needs to be reported. Laravel will determine what type of exception the closure reports by examining the type-hint of the closure:

use AppExceptionsInvalidOrderException;





  



                       
  









  



                       
  





/**
 * Register the exception handling callbacks for the application.
 */
public function register(): void
{
    $this->reportable(function (InvalidOrderException $e) {
        // ...
    });
}

When you register a custom exception reporting callback using the reportable method, Laravel will still log the exception using the default logging configuration for the application. If you wish to stop the propagation of the exception to the default logging stack, you may use the stop method when defining your reporting callback or return false from the callback:

$this->reportable(function (InvalidOrderException $e) {
    // ...
})->stop();
$this->reportable(function (InvalidOrderException $e) {
    return false;
});

Note
To customize the exception reporting for a given exception, you may also utilize reportable exceptions.

Global Log Context

If available, Laravel automatically adds the current user’s ID to every exception’s log message as contextual data. You may define your own global contextual data by defining a context method on your application’s AppExceptionsHandler class. This information will be included in every exception’s log message written by your application:

/**
 * Get the default context variables for logging.





  



                       
  





 *
 * @return array<string, mixed>
 */
protected function context(): array
{
    return array_merge(parent::context(), [
        'foo' => 'bar',
    ]);
}

Exception Log Context

While adding context to every log message can be useful, sometimes a particular exception may have unique context that you would like to include in your logs. By defining a context method on one of your application’s exceptions, you may specify any data relevant to that exception that should be added to the exception’s log entry:

<?php
namespace AppExceptions;
use Exception;
class InvalidOrderException extends Exception
{
    // ...
    /**
     * Get the exception's context information.
     *
     * @return array<string, mixed>





  



                       
  





     */
    public function context(): array
    {
        return ['order_id' => $this->orderId];
    }
}

The report Helper

Sometimes you may need to report an exception but continue handling the current request. The report helper function allows you to quickly report an exception via the exception handler without rendering an error page to the user:

public function isValid(string $value): bool
{
    try {





  



                       
  





        // Validate the value...
    } catch (Throwable $e) {
        report($e);
        return false;
    }
}

Exception Log Levels

When messages are written to your application’s logs, the messages are written at a specified log level, which indicates the severity or importance of the message being logged.

As noted above, even when you register a custom exception reporting callback using the reportable method, Laravel will still log the exception using the default logging configuration for the application; however, since the log level can sometimes influence the channels on which a message is logged, you may wish to configure the log level that certain exceptions are logged at.

To accomplish this, you may define a $levels property on your application’s exception handler. This property should contain an array of exception types and their associated log levels:

use PDOException;





  



                       
  





use PsrLogLogLevel;
/**
 * A list of exception types with their corresponding custom log levels.
 *
 * @var array<class-string<Throwable>, PsrLogLogLevel::*>
 */
protected $levels = [
    PDOException::class => LogLevel::CRITICAL,
];

Ignoring Exceptions By Type

When building your application, there will be some types of exceptions you never want to report. To ignore these exceptions, define a $dontReport property on your application’s exception handler. Any classes that you add to this property will never be reported; however, they may still have custom rendering logic:

use AppExceptionsInvalidOrderException;
/**
 * A list of the exception types that are not reported.
 *
 * @var array<int, class-string<Throwable>>
 */
protected $dontReport = [
    InvalidOrderException::class,
];

Internally, Laravel already ignores some types of errors for you, such as exceptions resulting from 404 HTTP errors or 419 HTTP responses generated by invalid CSRF tokens. If you would like to instruct Laravel to stop ignoring a given type of exception, you may invoke the stopIgnoring method within your exception handler’s register method:

use SymfonyComponentHttpKernelExceptionHttpException;
/**
 * Register the exception handling callbacks for the application.
 */
public function register(): void
{
    $this->stopIgnoring(HttpException::class);
    // ...
}

Rendering Exceptions

By default, the Laravel exception handler will convert exceptions into an HTTP response for you. However, you are free to register a custom rendering closure for exceptions of a given type. You may accomplish this by invoking the renderable method within your exception handler.

The closure passed to the renderable method should return an instance of IlluminateHttpResponse, which may be generated via the response helper. Laravel will determine what type of exception the closure renders by examining the type-hint of the closure:

use AppExceptionsInvalidOrderException;
use IlluminateHttpRequest;
/**
 * Register the exception handling callbacks for the application.
 */
public function register(): void
{
    $this->renderable(function (InvalidOrderException $e, Request $request) {
        return response()->view('errors.invalid-order', [], 500);





  



                       
  





    });
}

You may also use the renderable method to override the rendering behavior for built-in Laravel or Symfony exceptions such as NotFoundHttpException. If the closure given to the renderable method does not return a value, Laravel’s default exception rendering will be utilized:

use IlluminateHttpRequest;
use SymfonyComponentHttpKernelExceptionNotFoundHttpException;
/**
 * Register the exception handling callbacks for the application.
 */
public function register(): void
{





  



                       
  





    $this->renderable(function (NotFoundHttpException $e, Request $request) {
        if ($request->is('api/*')) {
            return response()->json([
                'message' => 'Record not found.'
            ], 404);
        }
    });
}

Reportable & Renderable Exceptions

Instead of defining custom reporting and rendering behavior in your exception handler’s register method, you may define report and render methods directly on your application’s exceptions. When these methods exist, they will automatically be called by the framework:

<?php





  



                       
  





namespace AppExceptions;
use Exception;
use IlluminateHttpRequest;
use IlluminateHttpResponse;
class InvalidOrderException extends Exception
{
    /**
     * Report the exception.
     */
    public function report(): void





  



                       
  





    {
        // ...
    }
    /**
     * Render the exception into an HTTP response.
     */
    public function render(Request $request): Response
    {
        return response(/* ... */);
    }





  



                       
  





}

If your exception extends an exception that is already renderable, such as a built-in Laravel or Symfony exception, you may return false from the exception’s render method to render the exception’s default HTTP response:

/**
 * Render the exception into an HTTP response.
 */
public function render(Request $request): Response|bool
{
    if (/** Determine if the exception needs custom rendering */) {
        return response(/* ... */);
    }





  



                       
  





    return false;
}

If your exception contains custom reporting logic that is only necessary when certain conditions are met, you may need to instruct Laravel to sometimes report the exception using the default exception handling configuration. To accomplish this, you may return false from the exception’s report method:

/**
 * Report the exception.
 */
public function report(): bool
{
    if (/** Determine if the exception needs custom reporting */) {
        // ...





  



                       
  





        return true;
    }
    return false;
}

Note
You may type-hint any required dependencies of the report method and they will automatically be injected into the method by Laravel’s service container.

HTTP Exceptions

Some exceptions describe HTTP error codes from the server. For example, this may be a «page not found» error (404), an «unauthorized error» (401), or even a developer generated 500 error. In order to generate such a response from anywhere in your application, you may use the abort helper:

abort(404);

Custom HTTP Error Pages

Laravel makes it easy to display custom error pages for various HTTP status codes. For example, to customize the error page for 404 HTTP status codes, create a resources/views/errors/404.blade.php view template. This view will be rendered for all 404 errors generated by your application. The views within this directory should be named to match the HTTP status code they correspond to. The SymfonyComponentHttpKernelExceptionHttpException instance raised by the abort function will be passed to the view as an $exception variable:

<h2>{{ $exception->getMessage() }}</h2>

You may publish Laravel’s default error page templates using the vendor:publish Artisan command. Once the templates have been published, you may customize them to your liking:

php artisan vendor:publish --tag=laravel-errors

Fallback HTTP Error Pages

You may also define a «fallback» error page for a given series of HTTP status codes. This page will be rendered if there is not a corresponding page for the specific HTTP status code that occurred. To accomplish this, define a 4xx.blade.php template and a 5xx.blade.php template in your application’s resources/views/errors directory.

Источник

() translation by (you can also view the original English article)

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

В первой половине статьи мы рассмотрим настройки по умолчанию, предоставляемые обработчиком исключений. Фактически, мы рассмотрим класс Handler, чтобы понять, как Laravel обрабатывает исключения.

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

Предварительная настройка

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

Откройте файл config/app.php. Давайте внимательно рассмотрим следующий фрагмент.

1
 
...

2
 
...

3
 
/*


4
 
|--------------------------------------------------------------------------


5
 
| Application Debug Mode


6
 
|--------------------------------------------------------------------------


7
 
|


8
 
| When your application is in debug mode, detailed error messages with


9
 
| stack traces will be shown on every error that occurs within your


10
 
| application. If disabled, a simple generic error page is shown.


11
 
|


12
 
*/

13
 








14




'debug' => env('APP_DEBUG', false),









15




...









16




...











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


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





  



                       
  






В дополнение к отображению ошибок, Laravel позволяет регистрировать ошибки в файле журнала. Давайте быстро рассмотрим варианты, доступные для ведения журнала. Опять же, перейдем к файлу config/app.php и внимательно рассмотрим следующий фрагмент.










1




...









2




...









3




'log' => env('APP_LOG', 'single'),









4












5




'log_level' => env('APP_LOG_LEVEL', 'debug'),









6




...









7




...











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


Файл журнала по умолчанию находится в файле storage/logs/laravel.log, и в большинстве случаев этого достаточно. С другой стороны, APP_LOG_LEVEL устанавливается в значение, которое указывает на серьезность ошибок, которые будут регистрироваться.


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


Затем давайте взглянем на класс Handler, который поставляется с приложением Laravel по умолчанию. Откройте файл app/Exceptions/Handler.php.










1




<?php









2












3




namespace AppExceptions;









4












5




use Exception;









6




use IlluminateAuthAuthenticationException;









7




use IlluminateFoundationExceptionsHandler as ExceptionHandler;









8












9




class Handler extends ExceptionHandler









10




{









11




    /**










12




     * A list of the exception types that should not be reported.










13




     *










14




     * @var array










15




     */









16




    protected $dontReport = [









17




        IlluminateAuthAuthenticationException::class,









18




        IlluminateAuthAccessAuthorizationException::class,









19




        SymfonyComponentHttpKernelExceptionHttpException::class,









20




        IlluminateDatabaseEloquentModelNotFoundException::class,









21




        IlluminateSessionTokenMismatchException::class,









22




        IlluminateValidationValidationException::class,









23




    ];









24












25




    /**










26




     * Report or log an exception.










27




     *










28




     * This is a great spot to send exceptions to Sentry, Bugsnag, etc.










29




     *










30




     * @param  Exception  $exception










31




     * @return void










32




     */









33




    public function report(Exception $exception)









34




    {









35




        parent::report($exception);









36




    }









37












38




    /**










39




     * Render an exception into an HTTP response.










40




     *










41




     * @param  IlluminateHttpRequest  $request










42




     * @param  Exception  $exception










43




     * @return IlluminateHttpResponse










44




     */









45




    public function render($request, Exception $exception)









46




    {









47




        return parent::render($request, $exception);









48




    }









49












50




    /**










51




     * Convert an authentication exception into an unauthenticated response.










52




     *










53




     * @param  IlluminateHttpRequest  $request










54




     * @param  IlluminateAuthAuthenticationException  $exception










55




     * @return IlluminateHttpResponse










56




     */









57




    protected function unauthenticated($request, AuthenticationException $exception)









58




    {









59




        if ($request->expectsJson()) {









60




            return response()->json(['error' => 'Unauthenticated.'], 401);









61




        }









62












63




        return redirect()->guest(route('login'));









64




    }









65




}











Существуют две важные функции, за которые отвечает класс Handler: сообщение и визуализация всех ошибок.


Давайте внимательно рассмотрим метод report.










1




/**










2




 * Report or log an exception.










3




 *










4




 * This is a great spot to send exceptions to Sentry, Bugsnag, etc.










5




 *










6




 * @param  Exception  $exception










7




 * @return void










8




 */









9




public function report(Exception $exception)









10




{









11




    parent::report($exception);









12




}











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


Затем давайте изучим метод render.










1




/**










2




 * Render an exception into an HTTP response.










3




 *










4




 * @param  IlluminateHttpRequest  $request










5




 * @param  Exception  $exception










6




 * @return IlluminateHttpResponse










7




 */









8




public function render($request, Exception $exception)









9




{









10




    return parent::render($request, $exception);









11




}











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





  



                       
  






Метод render также позволяет настраивать ответ для разных типов исключений, как мы увидим в следующем разделе.


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


Пользовательский класс исключения


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


Двигаемся дальше и создаем файл app/Exceptions/CustomException.php со следующим содержимым.










1




<?php









2












3




namespace AppExceptions;









4












5




use Exception;









6












7




class CustomException extends Exception









8




{









9




    /**










10




     * Report the exception.










11




     *










12




     * @return void










13




     */









14




    public function report()









15




    {









16




    }









17












18




    /**










19




     * Render the exception into an HTTP response.










20




     *










21




     * @param  IlluminateHttpRequest










22




     * @return IlluminateHttpResponse










23




     */









24




    public function render($request)









25




    {









26




        return response()->view(









27




                'errors.custom',









28




                array(









29




                    'exception' => $this









30




                )









31




        );









32




    }









33




}











Важно отметить, что класс CustomException должен расширять основной класс Exception. Для демонстрационных целей мы обсудим только метод render, но, конечно, вы также можете настроить метод report.


Как вы можете видеть, в нашем случае мы перенаправляем пользователей на страницу ошибок error.custom. Таким образом, вы можете создавать собственные страницы ошибок для определенных типов исключений.


Конечно, нам нужно создать соответствующий файл представления в resources/views/errors/custom.blade.php.










1




Exception details: <b>{{ $exception->getMessage() }}</b>











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


Нам также необходимо внести изменения в метод render файла app/Exceptions/Handler.php, чтобы наш пользовательский класс исключений мог быть вызван. Давайте заменим метод render следующим содержимым в файле app/Exceptions/Handler.php.










1




...









2




...









3




/**










4




 * Render an exception into an HTTP response.










5




 *










6




 * @param  IlluminateHttpRequest  $request










7




 * @param  Exception  $exception










8




 * @return IlluminateHttpResponse










9




 */









10




public function render($request, Exception $exception)









11




{









12




    if ($exception instanceof AppExceptionsCustomException)  {









13




        return $exception->render($request);









14




    }









15












16




    return parent::render($request, $exception);









17




}









18




...









19




...











Как вы можете видеть, сперва мы проверяем тип исключения в методе render. Если тип исключения — AppExceptionsCustomException, мы вызываем метод render этого класса.





  



                       
  






Итак, все уже готово. Далее, давайте продолжим и создадим файл контроллера в app/Http/Controllers/ExceptionController.php, чтобы мы могли протестировать наш собственный класс исключений.










1




<?php









2




namespace AppHttpControllers;









3












4




use AppHttpControllersController;









5












6




class ExceptionController extends Controller









7




{









8




    public function index()









9




    {









10




        // something went wrong and you want to throw CustomException










11




        throw new AppExceptionsCustomException('Something Went Wrong.');









12




    }









13




}











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










1




// Exception routes










2




Route::get('exception/index', 'ExceptionController@index');











И теперь вы можете открыть http://your-laravel-site.com/exception/index , чтобы узнать, работает ли он так, как ожидалось. Он должен отображать представление errors.custom в соответствии с нашей конфигурацией.


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


Вывод


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


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


Для тех из вас, кто только начинает работать с Laravel или хочет расширить свои знания, сайт или приложение с расширениями, у нас есть множество вещей, которые вы можете изучать на Envato Market.


Оставляйте свои идеи и вопросы ниже в комментариях!






Источник








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





  



                       
  






Конфигурация


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


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




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




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


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


Перехват/обработка исключений


Класс содержит метод register, в котором можно зарегистрировать пользовательский перехват исключений и рендеринг колбэков.


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


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


use AppExceptionsInvalidOrderException;
 
public function register() {
  $this->reportable(function (InvalidOrderException $e) {
    //
  });
}


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


$this->reportable(function (InvalidOrderException $e) {
  //
})->stop();
 
$this->reportable(function (InvalidOrderException $e) {
  return false;
});


Глобальный контекст для логирования


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


protected function context() {
  return array_merge(parent::context(), [
    'foo' => 'bar',
  ]);
}


Контекст конкретного исключения


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


Пример добавления информации с id заказа как контекст для исключения InvalidOrderException.


<?php
 
namespace AppExceptions;
 
use Exception;
 
class InvalidOrderException extends Exception
{
  public function context() {
    return ['order_id' => $this->orderId];
  }
}


Хэлпер report


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


public function isValid($value) {
  try {
    // проверка значения
  } catch (Throwable $e) {
    report($e);
    return false;
  }
}


Уровни логирования исключений


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


В связи с этим, вам наверняка захочется указать, какие ошибки и исключения должны считаться критическими, какие маловажными и т.д. Для этого реализуется свойство $levels в вашем классе обработчике исключений AppExceptionsHandler. В свойство передается массив из классов-исключений и уровни логирования.


Например, так можно сделать все исключения, связанные с PDO (базой данных) критическими:


use PDOException;
use PsrLogLogLevel;
 
/**
 * список соответствий между типами исключений и уровнями логирования
 *
 * @var array<class-string<Throwable>, PsrLogLogLevel::*>
 */
protected $levels = [
  PDOException::class => LogLevel::CRITICAL,
];


Игнорирование исключений


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


use AppExceptionsSomeException;

protected $dontReport = [
  SomeException::class,
];


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




За кулисами Laravel уже игнорирует некоторые типы исключений, такие как исключение возникающее при ответе 404 или 419 из-за невалидных csrf-токенов.




Рендеринг видов для исключений


Laravel уже по умолчанию настроен так, чтобы конвертировать исключения в HTTP-ответ. Однако, с помощью метода renderable вы можете регистрировать свои замыкания для определенных типов исключений, добавляя собственную логику в том числе и для отрисовки. Такое замыкание должно вернуть инстанс класса IlluminateHttpResponse, что можно добиться с помощью глобальной функции response.


Метод работает похожим на reportable образом, только принимает дополнительно объект запроса.


use AppExceptionsYourException;
 
public function register() {
  $this->renderable(function (YourException $e, $request) {
    return response()->view('errors.exc-view', [], 500);
  });
}


Вы можете использовать метод renderable в том числе и для того, чтобы переопределить логику отрисовки для встроенных исключений, таких как NotFoundHttpException, которое выбрасывается при http-ответе 404. Если вам нужно изменить логику отрисовки этого или любого другого встроенного исключения, вы можете это сделать.


use SymfonyComponentHttpKernelExceptionNotFoundHttpException;
 
public function register() {
  $this->renderable(function (NotFoundHttpException $e, $request) {
    if ($request->is('api/*')) {
      return response()->json([
        'message' => 'Объект не найден'
      ], 404);
    }
  });
}


Похожим образом можно переопределить логику отрисовки для любых других сценариев и HTTP-кодов.


Логика учета и отрисовки на уровне исключения


Вместо того, чтобы использовать методы reportable и renderable в классе обработчике исключений, можно реализовать методы report и render в самом классе исключения. Метод render принимает переменную $request с объектом запроса.


<?php
 
namespace AppExceptions;
 
use Exception;
 
class MyException extends Exception
{

  public function report() {
    //
  }

  public function render($request) {
    return response(/* ... */);
  }
}


Если вы наследуетесь от встроенного в Laravel исключения и хотите оставить логику отрисовки по умолчанию, можно вернуть false в методе render.


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


HTTP исключения


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


abort(404);


Кастомные страницы ошибок


Фреймворк предлагает простой способ кастомизации страниц ошибок. Например, если вы хотите сделать свою страницу 404 вместо имеющейся по умолчанию, можно создать вид resources/views/errors/404.blade.php.


Название вида должно совпадать с HTTP-кодом, для которого предназначена эта страница. В этом случае, если Laravel найдет соответствующую коду ответа страницу в resources/views/errors, то он отобразит ее вместо той, которая использовалась бы по умолчанию.


Инстанс класса исключения будет передан в вид автоматически и будет доступен в переменной $exception. 


<h2>{{ $exception->getMessage() }}</h2>


Шаблоны страниц по умолчанию для разных видов ошибок изначально находятся в папке vendor. Вы можете перенести их в папку resources/views/errors одной простой командой:


php artisan vendor:publish --tag=laravel-errors


После этого вы можете редактировать и адаптировать страницы ошибок под дизайн вашего проекта.


Fallback-страницы для HTTP-ошибок


Вы можете добавить специальные страницы, которые будут отрисовываться, если для кода HTTP-ответа не найдено соответствия с подходящей страницей. Для достижения этого, просто создайте в resources/views/errors файл с названием 4xx.blade.php или 5xx.blade.php. Первая будет  резервной fallback страницей для всех кодов группы 400 (клиентские ошибки), для которых нет своих страниц, а вторая для кодов группы 500 (серверные).








Источник






Обычно веб-разработчики не следят за ошибками. Если что-то идет не так, то мы частенько видим дефолтный текст ошибки Laravel: «Whoops, something went wrong» или, что еще хуже, код исключения, который посетителю совсем ни к чему. Поэтому я решил написать пошаговую статью о том, как элегантно обрабатывать ошибки и показывать посетителю правильную информацию о произошедшем.


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


Подготовка: Задача поиска пользователя


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




У нас есть два маршрута:


Route::get('/users', 'UserController@index')->name('users.index');
Route::post('/users/search', 'UserController@search')->name('users.search');


И контроллер с двумя методами:


class UserController extends Controller
{

    public function index()
    {
        return view('users.index');
    }

    public function search(Request $request)
    {
        $user = User::find($request->input('user_id'));
        return view('users.search', compact('user'));
    }

}


В файле resources/views/users/index.blade.php находится сама форма:


<form action="{{ route('users.search') }}" method="POST">
@csrf
<div class="form-group">
<input id="user_id" class="form-control" name="user_id" type="text" value="{{ old('user_id') }}" placeholder="User ID">
</div>
<input class="btn btn-info" type="submit" value="Search">
</form>


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




Всё это находится в resources/views/users/search.blade.php:


<h3 class="page-title text-center">User found: {{ $user->name }}</h3>
<b>Email</b>: {{ $user->email }}
<br>
<b>Registered on</b>: {{ $user->created_at }}


Но это в идеальном случае, а что, если пользователь не найден?


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


Давайте вернемся в реальный мир. Мы не проверяем существование пользователя, в контроллере мы только делаем:


$user = User::find($request->input('user_id'));


И, если пользователь не найден, то получим это:




Или, понятное дело, мы можем задать APP_DEBUG=false в файле .env, и тогда браузер просто покажет пустую страницу с «Whoops, looks like something went wrong». Но для нашего посетителя все это совершенно бесполезно.


Еще одно быстрое исправление, которое мы можем сделать, это использовать User::findOrFail() вместо просто find() — тогда, если пользователь не найден, Laravel покажет страницу 404 с текстом «Sorry, the page you are looking for could not be found». Но это дефолтная страница ошибки для всего сайта. Для посетителя она, опять таки, бесполезна.


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


Нам нужно знать тип исключения и имя класса, которое оно будет возвращать. В случае с findOrFail() будет выдано Eloquent исключение ModelNotFoundException, поэтому нам нужно сделать так:


public function search(Request $request)
{
    try {
        $user = User::findOrFail($request->input('user_id'));
    } catch (ModelNotFoundException $exception) {
        return back()->withError($exception->getMessage())->withInput();
    }
    return view('users.search', compact('user'));
}


Теперь давайте покажем ошибку в Blade:


<h3 class="page-title text-center">Search for user by ID</h3>

@if (session('error'))
<div class="alert alert-danger">{{ session('error') }}</div>
@endif

<form action="{{ route('users.search') }}" method="POST">...</form>


Результат:




Отлично, мы отобразили ошибку! Но это еще не идеал, верно? Вместо $exception->getMessage() нам нужно показать наше собственное сообщение:


return back()->withError('User not found by ID ' . $request->input('user_id'))->withInput();


Финальный вариант!




Перемещаем обработку ошибок в Сервис


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


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


Давайте переместим нашу логику в app/Services/UserService.php:


namespace AppServices;

use AppUser;
use IlluminateDatabaseEloquentModelNotFoundException;

class UserService
{

    public function search($user_id)
    {
        $user = User::find($user_id);
        if (!$user) {
            throw new ModelNotFoundException('User not found by ID ' . $user_id);
        }
        return $user;
    }

}


А в контроллере нам нужно вызвать этот сервис. Для начала мы внедрим его в метод __construct():


use AppServicesUserService;

class UserController extends Controller
{

    private $userService;

    public function __construct(UserService $userService)
    {
        $this->userService = $userService;
    }

// ...


Если вы не знакомы с внедрением зависимостей и как работает контейнер Laravel IOC, то вот официальная документация.


А вот так теперь выглядит наш метод search():


public function search(Request $request)
{
    try {
        $user = $this->userService->search($request->input('user_id'));
    } catch (ModelNotFoundException $exception) {
        return back()->withError($exception->getMessage())->withInput();
    }
    return view('users.search', compact('user'));
}


Обратите внимание, мы снова можем использовать $exception->getMessage(), вся проверка ошибок и логика сообщений происходит внутри службы. Мы удалили это из контроллера, он не должен заниматься этим.


Следующий Шаг: Создание собственного класса исключений


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


try {
  // Use Stripe's library to make requests...
} catch(StripeErrorCard $e) {
  // Since it's a decline, StripeErrorCard will be caught
  $body = $e->getJsonBody();
  $err  = $body['error'];

  print('Status is:' . $e->getHttpStatus() . "n");
  print('Type is:' . $err['type'] . "n");
  print('Code is:' . $err['code'] . "n");
  // param is '' in this case
  print('Param is:' . $err['param'] . "n");
  print('Message is:' . $err['message'] . "n");
} catch (StripeErrorRateLimit $e) {
  // Too many requests made to the API too quickly
} catch (StripeErrorInvalidRequest $e) {
  // Invalid parameters were supplied to Stripe's API
} catch (StripeErrorAuthentication $e) {
  // Authentication with Stripe's API failed
  // (maybe you changed API keys recently)
} catch (StripeErrorApiConnection $e) {
  // Network communication with Stripe failed
} catch (StripeErrorBase $e) {
  // Display a very generic error to the user, and maybe send
  // yourself an email
} catch (Exception $e) {
  // Something else happened, completely unrelated to Stripe
}


Итак, как мы можем создать наш собственный класс исключений? Очень просто — с помощью команды Artisan:


php artisan make:exception UserNotFoundException


Сгенерируется app/Exceptions/UserNotFoundException.php:


namespace AppExceptions;

use Exception;

class UserNotFoundException extends Exception
{
    //
}


Здесь же ничего нет, верно? Давайте заполним наше исключение логикой.

В этом классе может быть два метода:


    

  • report() — используется, если вы хотите сделать дополнительную запись в журнал — отправить сообщение об ошибке в BugSnag, на почту, в Slack и т. д.
    • 

  • render() — используется, если вы хотите сделать редирект с ошибкой или вернуть HTTP-ответ (например, свой собственный файл Blade ) непосредственно из класса Exception
    • 



Итак, для этого примера мы cделаем метод report():


namespace AppExceptions;

use Exception;

class UserNotFoundException extends Exception
{
    /**
     * Report or log an exception.
     *
     * @return void
     */
    public function report()
    {
        Log::debug('User not found');
    }
}


А вот так мы вызываем это исключение из контроллера:


public function search(Request $request)
{
    try {
        $user = $this->userService->search($request->input('user_id'));
    } catch (UserNotFoundException $exception) {
        report($exception);
        return back()->withError($exception->getMessage())->withInput();
    }
    return view('users.search', compact('user'));
}


Итак, это всё, что я хотел рассказать вам об обработке исключений и использовании Сервисов.


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


Подробнее об исключениях и обработке ошибок: официальная документация Laravel.


Автор: Povilas Korop

Перевод: Алексей Широков


Задать вопросы по урокам можно на нашем форуме.






Источник







  



                       
  





	









    
    
    
    



    

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

        
        

























    








			

  • Lc200 ошибка b1422
    • 

  • Lc1 ошибка самсунг как исправить ошибку
    • 

  • Lc 32rd8ru сброс ошибок
    • 

  • Lc 26d44ru сбросить ошибки
    • 

  • Lc 231 grundfos ошибка 25

    •