Error handling: What options do you need?

[SimonFrings]

One of our current idea is to make the ErrorHandler configurable. During discussion a few questions came up: What should be configurable options for this and what should be defaults for each option? Additionally should this ErrorHandler only being called for Exceptions or also for HTTP client/server error responses?

@clue and I are curious what you think about this topic!

[pfk84]

Additionally should this ErrorHandler only being called for Exceptions or also for HTTP client/server error responses?

That would already be a good configurable option... :) Other options could include:

• Display error details yes/no
• Log errors yes/no
• Specify PSR-3 logger
• Option to write to stderr, useful for containers

Also I'd like it to respect the Accept header so that e.g. in the case of Accept: application/json it doesn't return a HTML page but proper JSON.

[clue]

That would already be a good configurable option... :) Other options could include:

• Display error details yes/no
• Log errors yes/no
• Specify PSR-3 logger
• Option to write to stderr, useful for containers

The first one is definitely a high priority to avoid showing internal details in production environments 👍

The other three items make perfect sense and would likely end up being a single configuration option 👍👍👍 My Idea is to start with explicitly turning logging on or off to mimic the access log configuration discussed in #169.

Also I'd like it to respect the Accept header so that e.g. in the case of Accept: application/json it doesn't return a HTML page but proper JSON.

This is an interesting one! Makes we wonder if this should be built-in or if we should provide an interface to give consumers more control over this instead? WDYT?

[clue]

Small progress update 1 now that PR #173 has been merged 🎉 This changeset makes the existing ErrorHandler part of the public API. It can now be given explicitly to the App like this:

<?php

require __DIR__ . '/../vendor/autoload.php';

$app = new FrameworkX\App(
    new FrameworkX\ErrorHandler()
);

// Register routes here, see routing…

$app->run();

This is a starting point to add more options to control error handling in follow-up PRs as discussed here.

[clue]

Small progress update 2 now that PR #175 has been merged 🎉 This changeset adds support for loading the AccessLogHandler and ErrorHandler from the Container. They can now be given explicitly to the App like this:

<?php

require __DIR__ . '/../vendor/autoload.php';

$app = new FrameworkX\App(
    FrameworkX\AccessLogHandler::class,
    FrameworkX\ErrorHandler::class
);

// Register routes here, see routing…

$app->run();

On top of this, you may now configure the default handlers with an explicit DI container configuration like this:

<?php

require __DIR__ . '/../vendor/autoload.php';

$container = new FrameworkX\Container([
    FrameworkX\ErrorHandler::class => fn () => new FrameworkX\ErrorHandler()
]);

$app = new FrameworkX\App($container);

// Register routes here, see routing…

$app->run();

This is the next step in adding more options to control access logging and error handling in follow-up PRs as discussed here.

[JustSteveKing]

WHat I would find useful is a way to set my own ErrorHandler so that my API can respond with JSON by default even when it errors.

[pfk84]

You should be able to do that already l, although I never could get it to work, unfortunately...

[SimonFrings]

@JustSteveKing As @pfk84 also pointed out, you can use a custom ErrorHandler middleware for this. As the Framework X documentation says:

[...] You may also explicitly pass an ErrorHandler middleware to the App like this:

<?php

require __DIR__ . '/../vendor/autoload.php';

$app = new FrameworkX\App(
    new FrameworkX\ErrorHandler()
);

// …

It makes sense to add more control over the Errorhandler to Framework X, but we still have to figure out what is the right way to accomplish this. We recently shared our overview of some of the outstanding topics in Framework X on Twitter, which also contains changes for the ErrorHandler. I also gave a few insights about the future of the ErrorHandler in #238:

[...] I also talked with @clue as we have plans to change a few things about the Errorhandler in the future. For instance, we intend to remove the Errorhandler from the RouteHandler, rename it to ExceptionHandler, and give more control over this in total. At the moment, we do not have a precise timeline for when this will be added to the project. However, it is inevitable that there will be some BC-breaks involved in the process. The whole BC-break topic also depends on giving Framework X a first version on GitHub, which is our next priority.

To keep you updated, we're currently involved in working on the ReactPHP MySQL connection pool, as discussed in friends-of-reactphp/mysql#175, which will also benefit Framework X. After that, we want to give Framework X its first version, as we plan to introduce a few BC-Breaks in the future (move some files around, etc.). This way, we have proper versioning and can safely apply several changes.

Hope this gives a bit more context of the status of this feature and how we're going to move forward with Framework X! :)