Giter Site home page Giter Site logo

laravel-exceptions's Introduction

Laravel Exceptions

Laravel Exceptions was created by, and is maintained by Graham Campbell, and provides a powerful error response system for both development and production for Laravel. It optionally utilises the Whoops package for the development error pages. Feel free to check out the change log, releases, security policy, license, code of conduct, and contribution guidelines.

Banner

Build Status StyleCI Status Software License Packagist Downloads Latest Version

Installation

This version requires PHP 7.4-8.3 and supports Laravel 8-11.

Exceptions L5.5 L5.6 L5.7 L5.8 L6 L7 L8 L9 L10 L11
11.3
12.1
13.1
14.1
15.2
16.0
17.2

To get the latest version, simply require the project using Composer:

$ composer require "graham-campbell/exceptions:^17.2"

Once installed, if you are not using automatic package discovery, then you need to register the GrahamCampbell\Exceptions\ExceptionsServiceProvider service provider in your config/app.php.

You then MUST change your App\Exceptions\Handler to extend GrahamCampbell\Exceptions\ExceptionHandler.

Whoops Support

If you want to have the debug error pages available, you're going to need to require Whoops:

$ composer require "filp/whoops:^2.15" --dev

Our debug displayer will automatically detect the presence of Whoops. Feel free to go and have a read of our source code to give you a better understanding of how this works.

Configuration

Laravel Exceptions supports optional configuration.

To get started, you'll need to publish all vendor assets:

$ php artisan vendor:publish

This will create a config/exceptions.php file in your app that you can modify to set your configuration. Also, make sure you check for changes to the original config file in this package between releases.

There are a few config options:

Exception Transformers

This option ('transformers') defines each of the exception transformers setup for your application. This allows you to turn your exceptions into other exceptions such as exceptions for perfect results when passed to the displayers. Note that this list is processed in order and subsequent transformers can still modify the results of previous ones if required.

Exception Displayers

This option ('displayers') defines each of the exception displayers setup for your application. These displayers are sorted by priority. Note that when we are in debug mode, we will select the first valid displayer from the list, and when we are not in debug mode, we'll filter out all verbose displayers, then select the first valid displayer from the new list.

Displayer Filters

This option ('filters') defines each of the filters for the displayers. This allows you to apply filters to your displayers in order to work out which displayer to use for each exception. This includes things like content type negotiation.

Default Displayer

This option ('default') defines the default displayer for your application. This displayer will be used if your filters have filtered out all the displayers, otherwise leaving us unable to displayer the exception.

Exception Levels

This option ('levels') defines the log levels for the each exception. If an exception passes an instance of test for each key, then the log level used is the value associated with each key.

Usage

There is currently no usage documentation for Laravel Exceptions, but we are open to pull requests.

Security

If you discover a security vulnerability within this package, please send an email to [email protected]. All security vulnerabilities will be promptly addressed. You may view our full security policy here.

License

Laravel Exceptions is licensed under The MIT License (MIT).

For Enterprise

Available as part of the Tidelift Subscription

The maintainers of graham-campbell/exceptions and thousands of other packages are working with Tidelift to deliver commercial support and maintenance for the open source dependencies you use to build your applications. Save time, reduce risk, and improve code health, while paying the maintainers of the exact dependencies you use. Learn more.

laravel-exceptions's People

Contributors

4n70w4 avatar grahamcampbell avatar harreh avatar joecohens avatar lavatoaster avatar libern avatar m1guelpf avatar rcngo avatar stylecibot avatar thomasholman avatar vinkla avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

laravel-exceptions's Issues

CSRF expired error code

It's not an issue, it's a question. What was the reason to change default CSRF exception status code?

All non `HttpExceptionInterface` exceptions transformed to 500's?

So I'm finding that this package is causing a bit of grief with the exceptions.

Let's say I make an API request to get a resource, but my app denies the request through laravels ACL, this throws a AuthorizationException which does not implement the HttpExceptionInterface Interface.

Laravel doesn't add a code to this exception(it really should be a 401 or 403) so I wrote a transformer that returns the exception but with a 401 code.

The issue is that because it doesn't implement HttpExceptionInterface when this package uses Symfony's FlattenException the status code gets reset to 500 which is annoying, but manageable.

The real issue then comes in when we hit ExceptionInfo::generate
because again we don't Implement HttpExceptionInterface we end up with the generic information from the json file.

So by the time the user get's the error they see
selection_040

So basic question, why are we so reliant on HttpExceptionInterface?

Error pages (ie. 404) are not being shown; converts to a 500 page

After installing this package, our 404, 500, 503, etc pages are gone. All we get is a white page.

In bootstrap/app.php this is how I call your exceptionhandler

$app->singleton(
    'Illuminate\Contracts\Debug\ExceptionHandler',
    'GrahamCampbell\Exceptions\ExceptionHandler' // before: App\Exceptions\Handler.
);

If I change the ExceptionHandler to use the native App\Exceptions\Handler error pages are shown just fine. Therefore it must be something to do with your package.

If debugmode is true I see default Whoops page. If debug mode is false I see white pages.

404 pages gone

After installing this package, our 404 pages is gone. All we get is a white page on errors.

I guess it must be the same with 503, 500, etc. This is not so good, as it is running production.

Blade-based error pages with Blade directives or PHP code cause a default 500 Internal Server Error page to appear

Versions: Laravel 5.2, Laravel-Exceptions 8.4

If I try to invoke an error page that I have as a blade template that contains PHP or Blade directives (errors/404.blade.php), I get this error:

[2016-04-27 16:53:08] local.CRITICAL: exception 'Symfony\Component\Debug\Exception\FatalErrorException' with message 'Method Illuminate\View\View::__toString() must not throw an exception' in [...]/bootstrap/cache/compiled.php:0
Stack trace:
#0 {main} {"identification":{"id":"eeafdb97-45bb-495c-90cc-5c0f2a41790e"}}

Presumably the error page isn't actually being rendered and is instead being cast to String.

Middleware

We need a way to allow middleware to be run again on the error response. This is important for sending cookies for example. We need to make sure not to execute all the middleware, otherwise we could just crash again. We need some kind of middleware whitelist to re-execute on the response.

Output error templates

It will be great to have templates customizable via config/exceptions.php.

ExceptionsServiceProvider.php

$this->app->singleton(ExceptionInfo::class, function () {
    return new ExceptionInfo(__DIR__.'/../resources/errors.json');
});

$this->app->bind(HtmlDisplayer::class, function ($app) {
    return new HtmlDisplayer($app->make(ExceptionInfo::class), __DIR__.'/../resources/error.html');
});

Right now I need such things:

  • Multi language error message for json output:

./resources/views/errors/ru/error.json

  • Multi language error templates:

./resources/views/errors/ru/error.html

  • Have different templates dependent of Exception:

./resources/views/errors/ru/404.html (if Exception don't have template - use default one).

  • Application is separated on 2 parts: frontend & backend. Each of them got separate error templates for HtmlDisplayer (but I think this task is too complex and not so common to be included base package):

./resources/views/frontend/errors/ru/404.html

Issue with redirect responses

When running a test that throws a ValidationException laravel calls the followRedirects method, checks if the response is a redirect (which it is) and then tries to call getTargetUrl on the response.

Since Illuminate\Http\Response doesn't have a getTargetUrl method it fails.

Terminte Middleware

We should probably terminate middleware after rending exceptions. I'll need to check what's going on atm.

Composer install error

Problem 1

- The requested package graham-campbell/exceptions could not be found in any version, there may be a typo in the package name.

I was unable to install 1.1 version as it is not available, could you have a check and fix it?
But I am able to install 1.0 version from composer.

multiple languages error and configure.

Place the resource to have the possibility of multiple languages by configuring the config/exceptions.php or Accept-Language is another issue that would be very good is put in Json the possibility of changing the return, for example.

$error = [ 'type' => $ info['name'], 'message' => $info['detail'] ];

{
   "errors": [
     {
       "type": "not_found"
       "message": "O recurso solicitado não foi encontrado, mas pode estar disponível novamente no futuro."
     }
   ]
}

Illuminate\Contracts\Container\BindingResolutionException: Target [Illuminate\Contracts\Debug\ExceptionHandler] is not instantiable.

I was getting a "Illuminate\Contracts\Container\BindingResolutionException: Target [Illuminate\Contracts\Debug\ExceptionHandler] is not instantiable" error while running phpUnit under Laravel 5.2 and managed to replicate it on a new project with just Laravel-Exceptions. I tracked it down to possible a missing comment in the installation documentation.
It seems that, atleast on 5.2, you need to change the following in bootstrap\app.php

$app->singleton(
Illuminate\Foundation\Exceptions\Handler::class,
App\Exceptions\Handler::class
);

to

$app->singleton(
GrahamCampbell\Exceptions\ExceptionHandler::class,
App\Exceptions\Handler::class
);

Does that seem right? And if so, could you please add it to the installation description to help others?

Funny enough the site worked fine, just the phpUnit that was complaining about it.

Proposal Custom Displayers

I would really like to see custom displayers and the ability to customize the existing ones. My idea is to create a configuration file with all displayers that should be loaded as well as a default one. The configuration file would look something like to this:

/*
|--------------------------------------------------------------------------
| Default Exception Displayer
|--------------------------------------------------------------------------
|
| Here you may specify which of the exception displayers below you wish to
| use as your default displayer for all exceptions.
|
*/

'default' => 'plain',

/*
|--------------------------------------------------------------------------
| Exception Displayers
|--------------------------------------------------------------------------
|
| Here are each of the exception displayers setup for your application.
| Default displayers has been included, but you may add as many displayers
| as you would like.
|
*/

'displayers' => [
    'array' => 'GrahamCampbell\Exceptions\Displayers\ArrayDisplayer',
    'debug' => 'GrahamCampbell\Exceptions\Displayers\DebugDisplayer',
    'plain' => 'GrahamCampbell\Exceptions\Displayers\PlainDisplayer',
],

Each displayer class should have a class that we can call to determine if this displayer should be used or not. Currently named it use, there probably is a much better name.

/**
 * This is the array displayer class.
 *
 * @author Graham Campbell <[email protected]>
 */
class ArrayDisplayer implements DisplayerInterface
{
    /**
     * Get the content associated with the given exception.
     *
     * @param \Exception $exception
     * @param int        $code
     *
     * @return array
     */
    public function display(Exception $exception, $code)
    {
        $info = ExceptionInfo::generate($code, $exception->getMessage());

        return ['success' => false, 'code' => $info['code'], 'msg' => $info['extra']];
    }

    /**
     * The method to decide if this displayer should be used or not.
     *
     * @param \Exception               $exception
     * @param \Illuminate\Http\Request $request
     *
     * @return bool
     */
    public function use(Exception $exception, Request $request)
    {
        return $request->ajax();
    }
}

Then at last the getContent method in the ExceptionHandler class loops over the displayers specified in the configuration file and then sees which one to use. In this way we won't break any current setup. You wont have to publish the configuration if you don't want to.

What do you think @GrahamCampbell? Is this solution too complex?

how do i find error?

This error can be identified by f34cc10d-b30f-4e76-b199-9d4b78ab88e6. You might want to take a note of this code.

how I find error using the code above?

Empty page on error

So I installed the package following the instructions (like I did many times before). Though with this project I get an empty page and an 500 internal server error when it encounters an exception.

Error (after the not found or any other exception): exception 'ReflectionException' with message 'Class does not exist'. Traced it back to \GrahamCampbell\Exceptions\ExceptionHandlerTrait::getDisplayer where $this->config is null and it's trying to create a class null using $this->make() on line 121.

Now I know that's not supposed to be, so I traced back all my steps and tried from scratch a few times. No dice. Anything I'm missing? Laravel 5.1, "graham-campbell/exceptions": "~6.0", extended your handler, etc.


$container->config in \GrahamCampbell\Exceptions\ExceptionHandler on line 46 has no exceptions key.

Laravel 5.0* support?

Hi, it looks like this requires Laravel 5.1. Is there release for 5.0 distributions?

I'm getting the following response on composer update:

- Installation request for graham-campbell/exceptions ~3.0 -> satisfiable by graham-campbell/exceptions[v3.0.0].
- graham-campbell/exceptions v3.0.0 requires illuminate/contracts 5.1.* -> no matching package found.

Thanks!

Stacey

Allow to modify Whoops Handler in DebugDisplayer

I'd like to use the nice Whoops feature that allows to open the specified file directly in the editor. It requires calling setEditor() on the Handler object. Unfortunately this object can't be accessed outside of the package. Extending DebugDisplayer.php will be messy and will break updates. How about an extra config option or some other way to modify this handler?

Use with bugsnag

I am using bugsnag for my applications which means my handler.php is extending "Bugsnag\BugsnagLaravel\BugsnagExceptionHandler".

How can I use this package with bugsnag?

Laravel 5.3 compatiblity

Hi!

I just run a composer update to pull Laravel 5.3, and I catch this error message about your package:

PHP Fatal error:  Uncaught TypeError: Argument 1 passed to Illuminate\Foundation\Exceptions\Handler::__construct() must implement interface Illuminate\Contracts\Container\Container, instance of Illuminate\Log\Writer given, called in /Users/welcomattic/workspace/starfleet/vendor/graham-campbell/exceptions/src/ExceptionHandler.php on line 63 and defined in /Users/welcomattic/workspace/starfleet/vendor/laravel/framework/src/Illuminate/Foundation/Exceptions/Handler.php:46

Would you like to fix it, or if you want I can try to solve it and open a PR. As you want ;)

Thanks

White blank page if debug if false + Does not report to BugSnag

I am visiting a page, and all I get is a blank page.

I check bugsnag and nothing is there.

I have filled out my bugsnag api code.

Unable how to debug further.

I am also using your Logging package.

'loggers' => env('APP_DEBUG', false) ? ['Illuminate\Log\Writer' => ['*']] : [
    'AltThree\Bugsnag\Logger'   => ['error', 'critical', 'alert', 'emergency'],
    'AltThree\Logify\Logger'    => ['*']
],

I figured out it only happens if APP_DEBUG is false.

Getting error after install

I'm getting this after tried to install GrahamCampbell/Laravel-Exceptions package.
I already removed it and did composer install again but it's still the same.

Laravel 5.2

  [RuntimeException]
  Error Output: PHP Fatal error:  Uncaught ReflectionException: Class log does not exist in /Users/franco/Code/sendit/vendor/laravel/framework/src/Illuminate/Container/Container.php:738
  Stack trace:
  #0 /Users/franco/Code/sendit/vendor/laravel/framework/src/Illuminate/Container/Container.php(738): ReflectionClass->__construct('log')
  #1 /Users/franco/Code/sendit/vendor/laravel/framework/src/Illuminate/Container/Container.php(633): Illuminate\Container\Container->build('log', Array)
  #2 /Users/franco/Code/sendit/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(697): Illuminate\Container\Container->make('log', Array)
  #3 /Users/franco/Code/sendit/vendor/laravel/framework/src/Illuminate/Container/Container.php(853): Illuminate\Foundation\Application->make('log')
  #4 /Users/franco/Code/sendit/vendor/laravel/framework/src/Illuminate/Container/Container.php(808): Illuminate\Container\Container->resolveClass(Object(ReflectionParameter))
  #5 /Users/franco/Code/sendit/vendor/laravel/framework/src/Illuminate/Container/Container.php(777): Il in /Users/franco/Code/sendit/vendor/laravel/framework/src/Illuminate/Container/Container
  .php on line 738

Whoops page when AuthenticationException is thrown in laravel 5.3

There is an issue with new laravel 5.3 apps.

The new auth middleware Illuminate\Auth\Middleware\Authenticate throws an AuthenticationException when the user is not logged in. The default exception handler handles this by calling the unauthenticated method in the App\Exceptions\Handler.

https://github.com/laravel/framework/blob/5.3/src/Illuminate/Foundation/Exceptions/Handler.php#L135

Currently the GrahamCampbell\Exceptions\NewExceptionHandler does not handle this Exception in any particular way and ends up displaying the whoops page.

I made an example repo for reference:
https://github.com/scrubmx/issue-example/commits/master

Exception Levels

There is currently no way to set the logger level for exceptions. I think the ability to do that would be very useful.

ModelNotFoundException should be transformed into NotFoundHttpException

Default behavior in 5.2 now

namespace GrahamCampbell\Exceptions\Transformers;

use Exception;
use Illuminate\Database\Eloquent\ModelNotFoundException;
use Symfony\Component\HttpKernel\Exception\NotFoundHttpException;

/**
 * This is the auth transformer class.
 *
 * @author Graham Campbell <[email protected]>
 */
class ModelNotFoundTransformer implements TransformerInterface
{
    /**
     * Transform the provided exception.
     *
     * @param \Exception $exception
     *
     * @return \Exception
     */
    public function transform(Exception $exception)
    {
        if ($exception instanceof ModelNotFoundException) {
            $message = $exception->getMessage();
            $exception = new NotFoundHttpException($message ?: null);
        }

        return $exception;
    }
}

Lumen support

Should this work out-of-the-box for Lumen too? Doesn't seem to do anything.

[Question] Access the reference id in blade template

I have currently got the package installed using error blade files from my errors folder, everything is working fine but I can't seem to access the {{ $id }} for the error reference.

Is there anyway to access this from blade templates ? I have tried @{{ $id }} and just {{ $id }} but I'm not sure its even getting passed to them.

Exception handler only for Local?

Hi,

I wanna use your Whoops handler for Local development, and Bugsnag for production, but they both need the same changes in the Exceptions Handler.

use Exception;
#use Illuminate\Foundation\Exceptions\Handler as ExceptionHandler;
#use GrahamCampbell\Exceptions\ExceptionHandler as ExceptionHandler;
use Bugsnag\BugsnagLaravel\BugsnagExceptionHandler as ExceptionHandler;

class Handler extends ExceptionHandler {

Isn't there a way to use both?

This doesn't work of course :p

if(env('APP_ENV') == 'local')
{
    use GrahamCampbell\Exceptions\ExceptionHandler as ExceptionHandler;
}
else
{
    use Bugsnag\BugsnagLaravel\BugsnagExceptionHandler as ExceptionHandler;
}

Whoops

I am trying to install this project for my app, but I am not interested in the exceptions handler. Only the Whoops extension.

Can I install this package, and not having to worry about exceptions being thrown differently across my application?

Maintenance mode, php artisan down, throws an exception

Hi Graham,

Thanks for this great package.

I'm using Exceptions v8.6.1 and Laravel 5.2.39

When I run "php artisan down" an exception is thrown:

whoops outputs:

Symfony\Component\HttpKernel\Exception\HttpException 
...\vendor\laravel\framework\src\Illuminate\Foundation\Http\Middleware\CheckForMaintenanceMode.php:41
     * @param  \Illuminate\Http\Request  $request
     * @param  \Closure  $next
     * @return mixed
     *
     * @throws \Symfony\Component\HttpKernel\Exception\HttpException
     */
    public function handle($request, Closure $next)
    {
        if ($this->app->isDownForMaintenance()) {
            throw new HttpException(503);
        }

        return $next($request);
    }
}

This maintenance page shows fine when Laravel-Exceptions is not installed.

Thanks.

Incorrectly handles the error 404

In Laravel code using the method DB::whereSlug($slug)->firstOrFail(), which in the absence of the data automatically returns a 404 error and redirect it to the page.

Package an error Whoops:

Symfony\Component\HttpKernel\Exception\NotFoundHttpException thrown with message "No query results for model [App\News]."

\vendor\graham-campbell\exceptions\src\Transformers\ModelTransformer.php

public function transform(Exception $exception)
{
if ($exception instanceof ModelNotFoundException) {
$message = $exception->getMessage();
$exception = new NotFoundHttpException($message ?: null);
}

    return $exception;
}

I use default configuration, as in the documentation have not found how to customize the processing of certain error codes.

If you disable the debug mode, the redirection to the error page runs normally.

(Translated by Google Translate)

~2.0 tag not pushed?

Composer.json:

"require": {
        "laravel/framework": "5.0.*",
        "graham-campbell/exceptions": "~2.0"
    },
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - The requested package graham-campbell/exceptions could not be found in any version, there may be a typo in the package name.

Potential causes:
 - A typo in the package name
 - The package is not available in a stable-enough version according to your minimum-stability setting
   see <https://groups.google.com/d/topic/composer-dev/_g3ASeIFlrc/discussion> for more details.

Read <http://getcomposer.org/doc/articles/troubleshooting.md> for further common problems.

Generate Unique Error Codes

We should generate unique error codes and attach them to the logs, and present them to the user. That way if a user wants to contact support, they can provide us with the unique error code.

Laravels default Custom HTTP Error Pages broken

graham-campbell/exceptions package is causing that the default behavior of easily overwritable error response views isn't working anymore.

the feature from the docs:

Custom HTTP Error Pages Laravel makes it easy to return 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. This file will be served 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.

see; https://laracasts.com/discuss/channels/laravel/custom-http-error-pages-bugged

[5.3] ->validate(); exception bug

  • Laravel Version: 5.3.10
  • PHP Version: 7.0.9
  • Database Driver & Version: NaN

Description:

exception made but no redirection & no error msg

Steps To Reproduce:

  • controller
public function store(Request $request)
{
    $rules = [
        'image' => 'required|image|max:2048',
    ];

    Validator::make($request->all(), $rules)->validate();

    foreach ($request->image as $one) {
        $one->store('images', 'public');
    }

    return url('/')->with('success', 'done');
}
  • form
{{ Form::open(['route' => 'store.files', 'method' => 'POST', 'files'=>true]) }}
    {{ Form::file('image[]',['multiple']) }}
    <hr>
    {{ Form::submit('submit', ['class'=>'btn btn-success']) }}
{{ Form::close() }}
  • route
Route::post('/', [
    'as'   => 'store.files',
    'uses' => 'StoreController@store',
]);

screen shot 2016-09-26 at 10 16 45 am

on 5.2 it was working correctly , now when debug is true i get the above, when its false i get an error 500 page.

this is not the case if we instead used

$this->validate($request, [
   'image' => 'required|image|max:2048',
]);

contentType seems to be ignroed.

HtmlDisplayer is being served even the content type is Accept:application/json, text/javascript, /; q=0.01

public function contentType() {
      return 'text/html';
}

AuthenticationException not calling unauthenticated() method

Hi,

The default Laravel 5.3 error handler calls the unauthenticated() method when the error thrown is an instance of AuthenticationException. You can see this in https://github.com/laravel/framework/blob/5.3/src/Illuminate/Foundation/Exceptions/Handler.php#L133

Is there a specific reason that this method doesn't fire when using the NewExceptionHander? Is there a better way to redirect to a login page if the request is not authenticated?

The current way this is working means that the unauthenticated() method in App\Exceptions\Handler.php will never fire. Does this mean we need to be detecting the instance type and handling this ourselves in App\Exceptions\Hander::render() ?

    /**
     * Convert an authentication exception into an unauthenticated response.
     *
     * @param  \Illuminate\Http\Request  $request
     * @param  \Illuminate\Auth\AuthenticationException  $e
     * @return \Illuminate\Http\Response
     */
    protected function unauthenticated($request, AuthenticationException $e)
    {
        if ($request->expectsJson()) {
            return response()->json(['error' => 'Unauthenticated.'], 401);
        } else {
            return redirect()->guest('login');
        }
    }

Duplicate Content-Type Headers Causing Apache Error?

Installed Laravel-Exceptions with Whoops on a project. Threw an exception to test and was surprised to be greeted by a generic server-generated 500 error page instead of whoops. My apache logs (using MAMP) indicated that duplicate 'Content-Type' were causing an error. I inspected the response return by the GrahamCampbell\Exceptions\ExceptionHandler::render() method and noticed that it specified Content-Type: text/html where as Illuminate's handler did not.

I'm not sure where the content type is being inserted after the Handler does its thing, but this duplicate is clearly causing an issue. I was able to remedy the situation by doing the following, but a more permanent fix might be better.

public function render($request, Exception $e)
{
    if ($e instanceof ModelNotFoundException) {
        $e = new NotFoundHttpException($e->getMessage(), $e);
    }
    $response = parent::render($request, $e);
    $response->headers->remove('Content-Type');
    return $response;
}

ViewDisplayer doesn't use the current route middleware group

Not sure how feasible it would be to implement this, but if a request came in from the "web" (default) middleware group I'd love to see all the middleware for that still apply.

If there's an easy way to do this that I'm just missing, I can also take a look at the code and get it to work.

Thanks!

I found an issue that this doesn't able to catch FatalException

When under production mode,
if there is an error occurs in like say config/app.php,
anything, just type an "ServiceProvider" that doesn't exists to test the error:

  • it result that this page only display blank page with 500 error, and when i try catch
    parent::render($request, $e)
    the error is that "Class view does not exist"

However, for errors that occur in Controllers, Middlewares, are able to produce 500 Internal Server Error that this package provided.

Hope you know what I am mentioning about....

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.