Ошибка 404 laravel

Laravel is a PHP web application framework with expressive, elegant syntax. We’ve already laid the foundation — freeing you to create without sweating the small things.

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.

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:

use AppExceptionsInvalidOrderException;





  



                       
  





/**
 * Register the exception handling callbacks for the application.
 *
 * @return void
 */
public function register()
{
    $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 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:

/**
 * Get the default context variables for logging.
 *
 * @return array
 */
protected function context()
{
    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 custom 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
     */
    public function context()
    {
        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($value)





  



                       
  





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

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 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:

use AppExceptionsInvalidOrderException;
/**
 * A list of the exception types that are not reported.
 *
 * @var array<int, class-string<Throwable>>





  



                       
  





 */
protected $dontReport = [
    InvalidOrderException::class,
];

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:

use AppExceptionsInvalidOrderException;





  



                       
  





/**
 * Register the exception handling callbacks for the application.
 *
 * @return void
 */
public function register()
{
    $this->renderable(function (InvalidOrderException $e, $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 SymfonyComponentHttpKernelExceptionNotFoundHttpException;
/**
 * Register the exception handling callbacks for the application.
 *
 * @return void
 */
public function register()
{





  



                       
  





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

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:

<?php





  



                       
  





namespace AppExceptions;
use Exception;
class InvalidOrderException extends Exception
{
    /**
     * Report the exception.
     *
     * @return bool|null
     */
    public function report()





  



                       
  





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





  



                       
  





    {
        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.
 *
 * @param  IlluminateHttpRequest  $request
 * @return IlluminateHttpResponse





  



                       
  





 */
public function render($request)
{
    // Determine if the exception needs custom rendering...
    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.
 *








 * @return bool|null
 */
public function report()
{
    // Determine if the exception needs custom reporting...
    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, 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:

<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.

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

    • Отчет об исключениях
    • Игнорирование исключений по типу
    • Отображение исключений
    • Отчетные и отображаемые исключения
  • 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.

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
Источник
  1. 1. Настройка

    1. 1.1. Детализация ошибок
  2. 2. Обработка ошибок

    1. 2.1. Где разместить обработчики ошибок
  3. 3. Исключения HTTP
  4. 4. Обработка 404
  5. 5. Журнал

Этот перевод актуален для англоязычной документации на

25.05.2014

(ветка

4.1) и

16.10.2014

(ветка

4.0).
Опечатка? Выдели и нажми Ctrl+Enter.


+
4.1

добавлено в

4.1

(25.05.2014)

Настройка

Обработчик журналов для вашего приложения зарегистрирован в старт-файле app/start/global.php. По умолчанию регистратор событий настроен на использование одного файла для ведения журнала; но вы можете изменить это при необходимости. Так как Laravel использует популярную библиотеку для ведения журналов Monolog, вы можете воспользоваться различными обработчиками, которые она предлагает.

Например, если вы хотите использовать однодневные файлы журналов, а не один большой файл, вы можете сделать следующее изменение в вашем старт-файле:

PHP

$logFile = 'laravel.log';Log::useDailyFiles(storage_path().'/logs/'.$logFile);

Детализация ошибок

По умолчанию в Laravel включена детализация ошибок, происходящих в вашем приложении. Это значит, что при их возникновении будет отображена страница с цепочкой вызовов и текстом ошибки. Вы можете отключить детализацию ошибок установкой настройки debug файла app/config/app.php в значение PHPfalse.

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

Обработка ошибок

Файл app/start/global.php по умолчанию содержит обработчик любых исключений:

PHP

App::error(function (Exception $exception) {
  Log::error($exception);
});

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

PHP

App::error(function (RuntimeException $exception) {
  // Обработка исключения...
});

Если обработчик возвращает ответ, он будет отправлен в браузер и никакие другие обработчики вызваны не будут:

PHP

App::error(function (InvalidUserException $exception) {
  Log::error($exception);
  return 
'Извини! Что-то не так с этим аккаунтом!';
});

Вы можете зарегистрировать обработчик критических ошибок PHP методом PHPApp::fatal():

PHP

App::fatal(function ($exception) {
  //
});

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

Где разместить обработчики ошибок

Для регистрации обработчиков ошибок нет места по умолчанию. В этом Laravel предоставляет вам полную свободу. Одним из вариантов — определение обработчиков в вашем файле start/global.php. В общем это удобное расположение для размещения любого кода начальной загрузки. Если файл разрастается, то вы можете создать файл app/errors.php, и «запрашивать» этот файл из вашего скрипта start/global.php. Третий вариант — создать поставщик услуг, который будет регистрировать обработчиков. Опять же, здесь нет единственного «правильного» варианта. Выберите то место, которое вас устраивает.

Исключения HTTP

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

При желании, вы можете указать описание:

PHP

App::abort(403, 'Требуется авторизация.');

Этот метод может быть использован на любом этапе обработки запроса.

Обработка 404

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

PHP

App::missing(function ($exception) {
  return Response::view('errors.missing', array(), 404);
});

Журнал

Стандартный механизм журналирования представляет собой простую надстройку над мощной библиотекой Monolog. По умолчанию Laravel настроен для создания одного большого файла журнала для вашего приложения и хранения его в app/storage/logs/laravel.log. Вы можете записывать в него таким образом:

PHP

Log::info('Вот кое-какая полезная информация.');Log::warning('Что-то может идти не так.');Log::error('Что-то действительно идёт не так.');

Журнал предоставляет 7 уровней критичности, определённые в RFC 5424 (в порядке возрастания — прим. пер.): debug, info, notice, warning, error, critical и alert.

В метод записи можно передать массив данных о текущем состоянии:

PHP

Log::info('Log message', array('context' => 'Другая полезная информация.'));

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

PHP

$monolog = Log::getMonolog();

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

Отслеживание новых сообщений в журнале

PHP

Log::listen(function ($level, $message, $context) {
  //
});
Источник

Laravel 9 · Обработка ошибок

  • Введение
  • Конфигурирование
  • Обработчик исключений
    • Отчет об исключениях
    • Уровни регистрации исключений
    • Игнорирование исключений по типу
    • Отображение исключений
    • Отчетные и отображаемые исключения
  • 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;
    }
}

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

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

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

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

use PDOException;
use PsrLogLogLevel;

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

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

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

use AppExceptionsInvalidOrderException;

/**
 * Список типов исключений, о которых не следует сообщать.
 *
 * @var array<int, class-string<Throwable>>
 */
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.

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

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

Пользовательские страницы ошибок 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

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

Вы также можете определить «резервную» страницу ошибок для каждой серии кодов состояния HTTP. Эта страница будет отображаться, если нет соответствующей страницы для текущего кода состояния HTTP. Для этого определите шаблон 4xx.blade.php и шаблон 5xx.blade.php в каталоге resources/views/errors вашего приложения.

Источник

In this tutorial, we will see how to create custom 404 page in Laravel.

PHP Exceptions are similar to the exceptions in other programming languages. Exceptions are thrown when an error or an unknown event occurs. All PHP Exceptions extends the base Exception class.

Laravel provides app/Exceptions/Handler.php class that checks for all exceptions thrown in the application. Basically, every exception thrown in the application can be configured in this file and an appropriate response can be generated.

In this tutorial, we will see how to create a custom response for a 404 page. We are using Laravel 5.6. By default, Laravel returns a Whoops page back. We will see how to return a custom page depending on the exception. This will help you return a custom page for every HTTP Exception you want.

When someone hits a route that is not present, your site shows an error. It affects your SEO as well.

So, let’s see how we can manage 404 page, other HTTP exceptions, and Custom Exceptions in Laravel.

Setup Laravel Project

Let’s create a new laravel project. Run the following command to create a new project in a folder named errors.

composer create-project --prefer-dist laravel/laravel errors

Handling exceptions

All of the changes related to handling exceptions will be done in app/Exceptions/Handler.php. We will return a view when an error comes.

Custom 404 Page

Let’s create a custom 404 page in Laravel. In the app/Exceptions/Handler.php file, modify the render method.

/**
 * Render an exception into an HTTP response.
 *
 * @param  IlluminateHttpRequest  $request
 * @param  Exception  $exception
 * @return IlluminateHttpResponse
 */
public function render($request, Exception $exception)
{
    if ($this->isHttpException($exception)) {
        if ($exception->getStatusCode() == 404) {
            return response()->view('errors.' . '404', [], 404);
        }
    }

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

In the render method, we check if the exception is an HTTP exception. It is important because we are calling getStatusCode() method which is only available on HTTP exceptions. If the status code is 404, we return a view errors.404 with a status code as well. You can change the name of the view if you want.

We have to create a view for the 404 page. So, create a new view file errors/404.blade.php.

<!DOCTYPE html>
<html>
<head>
    <title>Page not found - 404</title>
</head>
<body>


The page your looking for is not available

</body>
</html>

If you want to create a custom page for any other HTTP exception, simply add a new if statement and change 404 with the new status code. Here’s the render method for handling 404 and 500 status code custom pages.

public function render($request, Exception $exception)
{
    if ($this->isHttpException($exception)) {
        if ($exception->getStatusCode() == 404) {
            return response()->view('errors.' . '404', [], 404);
        }
        
        if ($exception->getStatusCode() == 500) {
            return response()->view('errors.' . '500', [], 500);
        }
    }

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

Here’s the 404 response from our application.

custom 404 page laravel

Custom HTTP Exceptions pages

We can also automate this process. It would be great if we only have to create a new view file for the exception. The need to add code to the app/Exceptions/Handler.php file for every HTTP exception will no longer be required. In the app/Exceptions/Handler.php modify the render method.

public function render($request, Exception $exception)
{
    if ($this->isHttpException($exception)) {
        if (view()->exists('errors.' . $exception->getStatusCode())) {
            return response()->view('errors.' . $exception->getStatusCode(), [], $exception->getStatusCode());
        }
    }

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

Now, you are only required to create a view with the status code of the exception. render method will check if the view exists with the status code of the exception. If the view is present, it will simply return an HTTP response with that view and the status code.

For Example, we can create errors/404.blade.php for 404 error pages, errors/500.blade.php for 500 error pages and so on.

Handling Custom Exceptions

Let’s first create a custom exception. Run the following code to create an exception named TestingHttpException.

php artisan make:exception TestingHttpException

In the app/Exceptions/Handler.php file, modify the render method.

public function render($request, Exception $exception)
{
    if ($exception instanceof TestingHttpException) {
        return response()->view('errors.testing');
    }
    return parent::render($request, $exception);
}

If the exception is an instance of TestingHttpException, it will return errors.testing view.

You can also use the abort method with 404 code and it will serve an HTTP response with the custom 404 page.

You can use these techniques for handling all types of exceptions.

Learn more about Laravel:
Laravel Auth: Login With Email Or Username In One Field
Sending Notifications to Telegram Messenger with Laravel

Источник
  • Configuration
  • Handling Errors
  • HTTP Exceptions
  • Logging

Configuration

The logging facilities for your application are configured in the IlluminateFoundationBootstrapConfigureLogging bootstrapper class. This class utilizes the log configuration option from your config/app.php configuration file.

By default, the logger is configured to use daily log files; however, you may customize this behavior as needed. Since Laravel uses the popular Monolog logging library, you can take advantage of the variety of handlers that Monolog offers.

For example, if you wish to use a single log file instead of daily files, you can make the following change to your config/app.php configuration file:

'log' => 'single'

Out of the box, Laravel supported single, daily, syslog and errorlog logging modes. However, you are free to customize the logging for your application as you wish by overriding the ConfigureLogging bootstrapper class.

Error Detail

The amount of error detail your application displays through the browser is controlled by the app.debug configuration option in your config/app.php configuration file. By default, this configuration option is set to respect the APP_DEBUG environment variable, which is stored in your .env file.

For local development, you should set the APP_DEBUG environment variable to true. In your production environment, this value should always be false.

Handling Errors

All exceptions are handled by the AppExceptionsHandler class. This class contains two methods: report and render.

The report method is used to log exceptions or send them to an external service like BugSnag. By default, the report method simply passes the exception to the base implementation on the parent class where the exception is logged. 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 PHP instanceof comparison operator:

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

    return parent::report($e);
}

The render method is responsible for converting the exception into an HTTP response that should be sent back to the browser. By default, the exception is passed to the base class which generates a response for you. However, you are free to check the exception type or return your own custom response.

The dontReport property of the exception handler contains an array of exception types that will not be logged. By default, exceptions resulting from 404 errors are not written to your log files. You may add other exception types to this array as needed.

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 return such a response, use the following:

abort(404);

Optionally, you may provide a response:

abort(403, 'Unauthorized action.');

This method may be used at any time during the request’s lifecycle.

Custom 404 Error Page

To return a custom view for all 404 errors, create a resources/views/errors/404.blade.php file. This view will be served on all 404 errors generated by your application.

Logging

The Laravel logging facilities provide a simple layer on top of the powerful Monolog library. By default, Laravel is configured to create daily log files for your application which are stored in the storage/logs directory. You may write information to the log like so:

Log::info('This is some useful information.');

Log::warning('Something could be going wrong.');

Log::error('Something is really going wrong.');

The logger provides the seven logging levels defined in RFC 5424: debug, info, notice, warning, error, critical, and alert.

An array of contextual data may also be passed to the log methods:

Log::info('Log message', ['context' => 'Other helpful information']);

Monolog has a variety of additional handlers you may use for logging. If needed, you may access the underlying Monolog instance being used by Laravel:

$monolog = Log::getMonolog();

You may also register an event to catch all messages passed to the log:

Registering A Log Event Listener

Log::listen(function($level, $message, $context)
{
    //
});

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

Design by Jack McDade

Edit by ngnam

Источник

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

Читайте также:

  • Ошибка 404 dropbox что делать
  • Ошибка 404 beget
  • Ошибка 404 2ch
  • Ошибка 4037 при обновлении iphone через itunes
  • Ошибка 4032 флештул

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

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