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

Laravel is one of the best web development frameworks.

But does it have any error handling feature?

Yes. There is a default feature that helps to debug by making Laravel show PHP errors in the browser.

At Bobcares, we often get requests to turn on Laravel PHP errors as part of our Server Management Services.

Today, let’s see how our Support Engineers use the debug feature to troubleshoot errors.

How to make Laravel show PHP errors

By default, the Laravel framework has an error handling feature. The debug option in the configuration file determines the error display at the user end.

Usually, the Laravel configuration file that enables debugging is the config/app.php.  The debug option is set to default according to the APP_DEBUG variable in the .env file.

Basically, the .env file is a way to load custom configuration variables for Laravel. Hence, to make custom changes to Laravel, there is no need to modify web server files like .htaccess, virtual hosts and so on.

So, in the .env file, the APP_DEBUG variable is set to true to show PHP errors. This, in turn, changes the debug value in app.php to true. The debug option in app.php appear as,

Due to security reasons, showing errors all the time is also not recommended. Displaying Laravel PHP errors all the time in the browser will make the website vulnerable to website attacks.

Hence, our Support Team enables this feature only when we need to troubleshoot any error. After fixing the error, we turn off the debug feature.

Causes and fix for Laravel Debug not working

Sometimes, even after turning the debug value to true, Laravel does not show PHP errors. This is also a common request we often get from our customers. Let’s see how our Support Team fix this error.

1. Configuration setting in .env file

Some customers just change the debug value in config/app.php alone. This works fine in the production environment, but in the local environment, this does not display PHP errors.

So, our Support Team make sure that the following changes are made in .env file

APP_ENV=localAPP_DEBUG=true

When the configuration settings are proper then Laravel shows PHP errors in the browser. Due to security reasons, we always recommend our customers to turn on the debug feature only for troubleshooting.

2. Improper folder permissions

In some situations, the incorrect permissions of the storage and vendor directory in Laravel also causes the error. In this case, even the debug update in the .env file does not show PHP errors.

Usually, webserver needs write-access over Laravel folders storage and vendor.

For example, if the Apache web server is using a suPHP handler, then the PHP script runs with user permission. Thus the webserver will also have write permissions on the Laravel folders too.

But if the Apache webserver is running as a DSO module, then PHP application runs under nobody ownership. In this case, we need to give write permissions to the nobody user for using the Laravel folders.

Thus, our Support Engineers check the folder permissions and change it according to the web server in use.

3. The default setting in app.php

Occasionally, PHP files in the Laravel directory structure have some default settings that disable the debug feature.

For instance, the bootstrap directory contains an app.php file that loads the Laravel framework.

The app.php has some default settings, that comment some useful code related to debugging.

To fix this, we uncomment the line Dotenv::load(__DIR__.'/../'); in bootstrap/app.php to show PHP errors in Laravel.

Conclusion

So far, we saw how to make Laravel show PHP errors. We also discussed the possible errors that prevent error display in Laravel and how our Support Engineers fix them.

var google_conversion_label = «owonCMyG5nEQ0aD71QM»;

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

Design by Jack McDade

Edit by ngnam

• Introduction
• Configuration
• Обработчик исключений
  • Reporting Exceptions
  • Уровни журнала исключений
  • Игнорирование исключений по типу
  • Rendering Exceptions
  • Отчетные и отображаемые исключения
• HTTP Exceptions
  • Пользовательские страницы ошибок HTTP

Introduction

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

Configuration

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

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

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

Reporting Exceptions

Все исключения обрабатываются классом 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;});

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

Глобальный контекст журнала

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

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

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

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

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

report Helper

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

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

Уровни журнала исключений

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

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

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

use PDOException;use PsrLogLogLevel; protected $levels = [    PDOException::class => LogLevel::CRITICAL,];

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

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

use AppExceptionsInvalidOrderException; protected $dontReport = [    InvalidOrderException::class,];

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

Rendering Exceptions

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

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

use AppExceptionsInvalidOrderException; public function register(){    $this->renderable(function (InvalidOrderException $e, $request) {        return response()->view('errors.invalid-order', [], 500);    });}

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

use SymfonyComponentHttpKernelExceptionNotFoundHttpException; 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{        public function report()    {        

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

public function render($request){    

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

public function report(){    

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

HTTP Exceptions

Некоторые исключения описывают коды ошибок 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, используя Artisan-команду vendor:publish . После публикации шаблонов вы можете настроить их по своему вкусу:

php artisan vendor:publish 

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

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

Laravel

9.3

• Encryption

• Laravel Envoy

• Events

• Queued Event Listeners

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. После публикации шаблонов вы можете настроить их по своему вкусу:

Источник