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

[libern]

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

[GrahamCampbell]

Not an issue with this. This will happen with laravel too. This happens if something "fucked up" before the app was ready. Nothing we can really do.

[GrahamCampbell]

If something messes up during the early boot stages, expect either a php fatal error, or errors regarding resolution from the ioc.

[libern]

But if something "fucked up" before the app was ready, why the laravel is able to display the page like "Whoops, something went wrong". if you look at this line

new SymfonyDisplayer(config('app.debug')))->createResponse($e)

it will actually help to produce the 500 error page even before app is ready.

[GrahamCampbell]

Hmmm, I guess we could show that page too if the view component isn't ready.

[GrahamCampbell]

What was the whole error please?

[GrahamCampbell]

Did it happen on this line?

https://github.com/GrahamCampbell/Laravel-Exceptions/blob/master/src/ExceptionHandler.php#L111

[libern]

Oh yah! Thanks for understanding this, actually I am like your production error page, it is nice!

[libern]

It happened at this line:
https://github.com/GrahamCampbell/Laravel-Exceptions/blob/master/src/Displayers/PlainDisplayer.php#L58

[libern]

I think if you want to display the page, you should manually create the error page content like Symfony did without depending on the View.

[GrahamCampbell]

What I'm going to do is make a SymfonyDisplayer, and if the normal error page failed to render, we'll use the symfony one.

[libern]

Whats a pity.. If goes for this way to solve the problem, the objective to replace Symfony cannot be meet any more.

Because I just don't like the UI of the original one.

I suggest that maybe you could made a Static html file and string and return it if View is not available.

Best Regards,
Libern

On 12 May 2015, at 16:56, Graham Campbell notifications@github.com wrote:

What I'm going to do is make a SymfonyDisplayer, and if the normal error page failed to render, we'll use the symfony one.

—
Reply to this email directly or view it on GitHub.

[GrahamCampbell]

I suggest that maybe you could made a Static html file and string and return it if View is not available.

The idea here is to fall back to something we know will work. Symfony will always return something.

[GrahamCampbell]

Even if we've made a right mess, and even if we've used all the memory.

[libern]

Okay then. Thanks anyway :)

[GrahamCampbell]

So, are you going to use my solution, or role you're own. If you don't like my solution, just say, and we can do something else. Your idea of the static file would work just fine also. Could you send a pull to do it?

[GrahamCampbell]

That is, if you'd prefer it over my one. :)

[libern]

I think it is possible to keep your one consistent like Symfony did. May be I will try to find a workaround to make it works like Symfony and send a pull.

[GrahamCampbell]

@libern Can you confirm that "~2.0" now totally works for you please?

[libern]

@GrahamCampbell Hi, I have just tested this package, it shows the problem with path to the plain.html.

'exception 'ErrorException' with message 'file_get_contents(resources/plain.html): failed to open stream: No such file or directory' in /Users/Libern/vendor/graham-campbell/exceptions/src/Displayers/PlainDisplayer.php:48
Stack trace:
#0 [internal function]: Illuminate\Foundation\Bootstrap\HandleExceptions->handleError(2, 'file_get_conten...', '/Users/Libern/P...', 48, Array)
#1 /Users/Libern/vendor/graham-campbell/exceptions/src/Displayers/PlainDisplayer.php(48): file_get_co'...

[libern]

May be I do it wrongly, please advise the correct way to do..

[GrahamCampbell]

Hmmm, maybe we still need the __DIR__ in there.

[libern]

Yup. maybe that will works

[GrahamCampbell]

@libern Did my last commit fix this for you?

[GrahamCampbell]

I've just added a test for it, and it seems to be working. Could you confirm please?

[libern]

Yeah! It works! Thanks man!

[GrahamCampbell]

Great. I'll be doing the 2.0.0 release sometime soon. :)

[libern]

Nice! I am waiting for the release and will change to the stable version instead of @dev.

[GrahamCampbell]

I've just made a load more major changes. What do you think of them?

[libern]

After saw all codes that have been changed so far, I have following points in mind:

1. Would it possible that we can separate config arrays for each debug and non-debug, this could reduce the 'for loop'.

2. In actual development, what we want to see is categorised into following:

in debug mode

• Whoops Error display, for normal request
• Json Error Response, for request that wants json

in production mode

• Plain error page display, 500 for any errors/exceptions

Instead of being configurable for own displayer, we should provides ways to custom the production error page. For debug mode, I think whoops handle it quite well.

3. Instead of filtering the displayer by looping through the displayers, I think it is quite simply and straight forward, to return displayer based on the request and debug mode.

4. if people still wants to custom their own displayers, we should force them to implement either one of existing type of displayers by extending or interface as the error situation is fixed and expectable.

5. Thanks for great works here! I am loving it :)

[GrahamCampbell]

1. Not sure how that would work. The idea here is that the non-debug providers are still used in debug if the debug specific ones are for the incorrect content type.

2. I'm not sure what you mean? This is how things work atm:

• Non-debug:
  1. accepts anything or accepts html only - you get the html displayer
  2. accepts json only - you get the json displayer
• Debug:
  1. accepts anything or accepts html only - you get the debug displayer
  2. accepts json only - you get the json displayer

3. It's not that simple, because the accept header can contain multiple content types, so we need to match it to the best displayer.

4. As long as people match our interface, then I don't think it matters?

5. 🍻

[GrahamCampbell]

Would it possible that we can separate config arrays for each debug and non-debug, this could reduce the 'for loop'.

Just had this in the back of my mind since you suggested it. I think it might be a good idea.

Ping @vinkla, @jbrooksuk, and @joecohens. What do you guys think. This would mean we'd be ditching the idea of displayers deciding if they're verbose, and letting the user configure them.

I'm undecided atm.

[GrahamCampbell]

we should provides ways to custom the production error page

We do don't we?

1. We allow people to extend our html displayer and modify it to what they want.
2. We have a canDisplay method so people can make their own displayers, then do advanced logic based on the request and/or the exception thrown to decide what sort of error page to display.

[joecohens]

Yeah they can easily extend the displayers. Maybe we could have a global debug mode or something like that. Because all other things are covered if you extend the displayer and overwrite the methods and you could have any logic intended. Even the debug option can be made per displayer.

[GrahamCampbell]

Maybe we could have a global debug mode or something like that.

We already have that - we use laravel's. :)

[GrahamCampbell]

Even the debug option can be made per displayer.

The idea is that you put the debug displayers in the config infront of the non-debug ones, so that displayer is preferred when we work out which one to use.

[joecohens]

Oh ok ok! I think it would be cool. :)