What does phpErrorHandler do?

I am asking because I have overridden all the other error handlers to provide pretty errors, but nothing seems to be catching PHP errors. That sure sounds like what phpErrorHandler should do, but doesn’t in my case.


// dependencies.php

$container['errorHandler'] = function ($c) {
	$settings = $c->settings['displayErrorDetails'];
	return new App\Handlers\Error($c->view, $settings);

$container['notFoundHandler'] = function ($c) {
	throw new \App\Handlers\Exception(404, 'The page you are looking for could not be found.');

$container['notAllowedHandler'] = function ($c) {
	throw new \App\Handlers\Exception(405, 'Method ' . $c->request->getMethod() . ' is not allowed.');

$container['phpErrorHandler'] = function ($c) {
	throw new \App\Handlers\Exception(500, 'Unexpected application error has occurred.');

The phpErrorHandler catches PHP7’s Throwables, so it handles engine-level errors.

Thank you for the reply and I realize now that I did a really poor job of asking my question. So, I will try to do better this time around.

What is an example of an error that will trigger the native phpErrorHandler? I have commented out all my custom error handling and put a break on PhpError’s __construct and __invoke they never get called.

Here are a couple of cases I have tried under this scenario:

  1. Create fatal php error (see below).

     $foo = 0;

    This will return…

     PHP Fatal error:  Call to a member function bar() on a non-object...
  2. Call route using unsupported method like ‘SEARCH’.

    This will return…

     PHP Fatal error:  Uncaught exception 'InvalidArgumentException' with message 'Unsupported HTTP method "SEARCH" provided' in ...

For starters, are you indeed using PHP7? Otherwise Throwable will not even exist.

No, I am using PHP 5.5.32, so I guess that’s a problem. However, I was under the impression that 5.5.0 or newer was supported? How can that be if a PHP 7 interface is required? Am I supposed to hook the set_error_handler(…) myself in PHP 5.5.x?

With that said, I really like Slim and appreciate all the hard work that has gone into it. The error handling is the only thing I’ve found to be a bit “odd”. I don’t understand why there are multiple handlers each having different interfaces. Also, looking at the code, there is a bunch of duplicate code going on in each of those handlers.

I mean, in practical terms, these handlers are processing exceptions right? NotFound, MethodNotAllowed, etc. are going to stop the show. So, it seems to me that internally throwing a SlimException with a proper status code for NotFound, MethodNotAllowed, etc. would allow you to do everything you’re doing today. But, it would allow us end users to override a single handler that was being passed a SlimException. Heck, you really don’t even need the SlimException if you can pass the Request and Response to the single handler.

This just seems pretty straight forward to me, and it’s pretty much what I’m doing (after the fact) in the code shown in my original post. I’m sure there are valid reasons for what is being done now and I’d like to hear your thoughts.


If you are not using PHP7 you wont need the phpErrorHandler.

For exceptions in PHP5.x the errorHandler is called, you can forget about the phpErrorHandler

The reason for this is that Slim support both PHP 5.5+ and PHP7