Laravel включить вывод ошибок

Error Handling

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.

For example, 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 deduce what type of exception the closure reports by examining the type-hint of the closure:

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:

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 overriding the context method of your application’s AppExceptionsHandler class. This information will be included in every exception’s log message written by your application:

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 custom exceptions, you may specify any data relevant to that exception that should be added to the exception’s log entry:

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:

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 an array of exception types and their associated log levels within the $levels property of your application’s exception handler:

Ignoring Exceptions By Type

When building your application, there will be some types of exceptions you simply want to ignore and never report. Your application’s exception handler contains a $dontReport property which is initialized to an empty array. Any classes that you add to this property will never be reported; however, they may still have custom rendering logic:

Note
Behind the scenes, Laravel already ignores some types of errors for you, such as exceptions resulting from 404 HTTP «not found» errors or 419 HTTP responses generated by invalid CSRF tokens.

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 via the renderable method of 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 deduce what type of exception the closure renders by examining the type-hint of the closure:

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:

Reportable & Renderable Exceptions

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

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:

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:

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:

Custom HTTP Error Pages

Laravel makes it easy to display custom error pages for various HTTP status codes. For example, if you wish 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 on 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:

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:

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.

Laravel is a web application framework with expressive, elegant syntax. We believe development must be an enjoyable and creative experience to be truly fulfilling. Laravel attempts to take the pain out of development by easing common tasks used in most web projects.

Источник

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Помощник report

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

Laravel is a trademark of Taylor Otwell. Copyright © Taylor Otwell.

Design by Jack McDade

Edit by ngnam

Вступление

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

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

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

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

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

Метод отчета

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

Например, если вам нужно сообщать о различных типах исключений по-разному, вы можете использовать instanceofоператор сравнения PHP :

/**
 * Report or log an exception.
 *
 * This is a great spot to send exceptions to Sentry, Bugsnag, etc.
 *
 * @param  Exception  $exception
 * @return void
 */
public function report(Exception $exception)
{
    if ($exception instanceof CustomException) {
        //
    }

    parent::report($exception);
}

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

Контекст глобального журнала

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

/**
 * Get the default context variables for logging.
 *
 * @return array
 */
protected function context()
{
    return array_merge(parent::context(), [
        'foo' => 'bar',
    ]);
}

reportHelper

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

public function isValid($value)
{
    try {
        // Validate the value...
    } catch (Exception $e) {
        report($e);

        return false;
    }
}

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

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

/**
 * A list of the exception types that should not be reported.
 *
 * @var array
 */
protected $dontReport = [
    IlluminateAuthAuthenticationException::class,
    IlluminateAuthAccessAuthorizationException::class,
    SymfonyComponentHttpKernelExceptionHttpException::class,
    IlluminateDatabaseEloquentModelNotFoundException::class,
    IlluminateValidationValidationException::class,
];

Метод рендеринга

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

/**
 * Render an exception into an HTTP response.
 *
 * @param  IlluminateHttpRequest  $request
 * @param  Exception  $exception
 * @return IlluminateHttpResponse
 */
public function render($request, Exception $exception)
{
    if ($exception instanceof CustomException) {
        return response()->view('errors.custom', [], 500);
    }

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

Отчетные и визуализируемые исключения

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

<?php

namespace AppExceptions;

use Exception;

class RenderException extends Exception
{
    /**
     * Report the exception.
     *
     * @return void
     */
    public function report()
    {
        //
    }

    /**
     * Render the exception into an HTTP response.
     *
     * @param  IlluminateHttpRequest
     * @return IlluminateHttpResponse
     */
    public function render($request)
    {
        return response(...);
    }
}

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

Исключения HTTP

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

abort(404);

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

abort(403, 'Unauthorized action.');

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

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

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

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

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