Download the PHP package winternight/laravel-error-handler without Composer
On this page you can find all versions of the php package winternight/laravel-error-handler. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download winternight/laravel-error-handler
More information about winternight/laravel-error-handler
Files in winternight/laravel-error-handler
Package laravel-error-handler
Short Description Error handler package for the Laravel 5 framework
License MIT
Homepage https://github.com/darkwinternight/laravel-error-handler
Informations about the package laravel-error-handler
⚠️ No longer maintained
Fortunately, Laravel 5.5 has brought back the Whoops error handler and this has continued throughout Laravel 5.6 and now 5.7.
This repository and package can still be used for Laravel 5.2 and 5.3 and will continue to work. I will not add Laravel 5.4 support because Laravel 5.4 itself is no longer supported.
Issue reports and pull requests on this repository will not be attended.
Laravel 5.2/5.3 Error Handler
Unlike version 4, Laravel 5 no longer uses Whoops error handling out of the box and instead relies on the Symfony error handler, which is far less informative for developers.
This packages provides a convenient way to get the more informative Whoops error messages back in your Laravel 5.2/5.3 project, along with a few other goodies.
Features
- Optional Whoops 1.1 or 2.1 exception handler in debug mode
- Standard (and configurable) error views in production mode
- Provides AJAX-compatible JSON error responses in case of an exception (including HTTP exceptions)
- Fires an event for each exception, providing full access to the exception
- Compatibility with Laravel Debug Bar
Installation
To get the latest version of Laravel Error Handler, simply require the project using Composer:
Instead you can of course manually update the require
block in your composer.json
and add the laravel-error-handler
package.
Whoops
Whoops itself is an optional dependency and you can do without Whoops on production. To install it, simply run:
Both Whoops ^1.1
and ^2.1
are supported but I strongly recommend you use the latest version, especially if you already use PHP 7.
Configuration
Add the service provider in your config/app.php
:
You then need to change your App\Exceptions\Handler
class to extend Winternight\LaravelErrorHandler\Handlers\ExceptionHandler
rather than extending Illuminate\Foundation\Exceptions\Handler
.
Thats it — better error handling for your Laravel 5 project!
Usage
Normally, you don't have to do anything special. As long as debug mode is enabled in your Laravel application (that is,
app.debug
is set to true
) and Whoops is installed, you should see the Whoops error handler.
Debug Mode vs. Plain Mode
In debug mode, the Whoops handler is being shown. Since it exposes a lot of information about your system, your source
code and potentially even passwords to your database and other services (depending on what you store in your .env
file
and thus your environment variables), debug mode should never, ever be enabled on a production environment (or any
environment that is exposed to the outside world).
If app.debug
is enabled and Whoops is not installed, it will fall back to the Laravel 5 way of displaying exceptions.
Because you will proably need pretty error pages for your application anyway, this package takes care of that for you.
If debug mode is disabled (app.debug
is set to false
), an error view is rendered instead. By default, the view being
rendered is errors.error
(that will be views/errors/error.blade.php
for most of us). If you want to change that, you
can set a view in config/view.php
like this (this example would use the views/error/exception.blade.php
view):
HTTP Exceptions
For HTTP exceptions like 404
, 403
and so on, the package will try to find a corresponding view. For example, to use
a different view for 404
errors, you can simply create a views/errors/404.blade.php
file and it will be used
automatically.
Maintenance Mode
By default, Laravel uses a custom view in maintenance mode
to make it easy to disable your application while it's updating. The default template for maintenance mode responses is
located in views/errors/503.blade.php
. If you remove that file, this package still has you covered: Laravel's
maintenance mode simply throws an exception with a 503
HTTP status code, so you will be shown the default error view
when your application's debug mode is off. With debug mode turned on, you will be shown the actual exception with the
Whoops error handler.
Events
Whenever an error occurs, an ExceptionEvent
is raised. You can use your EventServiceProvider
to listen to this type
of event if you wish:
Is this compatible with Laravel Debug Bar?
I'm glad you asked! Yes, it is. The debug bar simply renders on top of the Whoops error page. You can also use the Event
that is being fired whenever an exception occurs to add it to your debug bar. Here's a small example which you can put
in your EventServiceProvider
's boot()
method:
Troubleshooting
If you're not seeing any difference (and you have made sure there actually is an error being thrown, you probably have debugging disabled. That means that Laravel will (and should) not disclose any details regarding the error that has occurred. It's for your own protection.
To enable Whoops, open up your config/app.php
configuration file, find the debug
setting and change it to true
. As
soon as you encounter an error, you will see the Whoops error handler. If you have done everything right, you should
probably use the .env
file to set the APP_DEBUG
environment variable.
What about AJAX requests?
Whenever an AJAX request triggers the error handler, it will be recognized and the so called PrettyPageHandler
will be
exchanged for a JsonResponseHandler
that returns a JSON response that you can parse on the client side. You can read
more here.
If debug mode is turned off, a different JSON object will be returned instead that still allows you to gracefully handle
your AJAX errors, while not giving out any information about your code.
Here is a (very) simple jQuery snippet for global AJAX error handling:
The JSON object will always contain an error
property which in turn will always at least contain the type
and message
properties. If debug mode is enabled, it will additionally contain the file
and line
properties and — in case of an
Exception — also the trace
property. The trace
property contains the full exception stack trace.
What about errors in the console?
The package is smart enough not to mess with output to the console. Enjoy your errors in plain text!
All versions of laravel-error-handler with dependencies
illuminate/contracts Version 5.2.*|5.3.*
illuminate/support Version 5.2.*|5.3.*
symfony/debug Version ^2.7|^3.0
symfony/http-foundation Version ^2.7|^3.0
psr/log Version ^1.0