Error handling still problematic

[plasid]

This issue had been raised before.
A lot of boilerplate code is needed to implement error handling, but the main problem is how Slim handles and overrides this internally, and then the order of defining middlewares and error handling in a complex application, you should not have to read the docs for this, cause if you miss it or do it wrong then your error handling will not work correctly.
Imagine a typical scenario where you need to handle and log ALL types of errors gracefully with your own views loggers etc, including fatal errors, this means in some cases your error handling needs to be "active" even before Slim boots, now reading the docs and tutorials it becomes an absolute verbose mess.

I've been working with Slim for a few years and error handling remains a pain point.
Can I suggest that you either remove error handling completely from the core and only throw, and the developer can wrap the application with error handlers any way he/she sees fit.
Or at least supply a configuration option to disable Slim's error handling completely.
Its really a trivial matter and should not be this complicated.

[odan]

Thank you for your comprehensive feedback. It's clear that you have a deep understanding of Slim 4 and its error-handling mechanisms, and we value your perspective.

First, I wanted to add some clarification about PHP error types to our conversation. As you're likely aware, PHP has multiple types of "errors":

• Traditional PHP Errors: These include E_NOTICE, E_WARNING, E_ERROR, etc.
• Exception-based Errors: These involve try-catch blocks and are part of the Exception hierarchy.

In its current form, Slim's ErrorHandler is designed to catch and handle exception-based errors, but it doesn't natively handle traditional PHP errors. The core framework expects you to handle these kinds of errors separately, and you can use PHP's own register_shutdown_function() and set_error_handler() functions or similar mechanisms such as Symfony ErrorHandler.

use Symfony\Component\ErrorHandler\ErrorHandler;
// ...

// Throw an exception when a PHP error occurs
// and handled it with the Slim error handler.
ErrorHandler::register();

Regarding your concern about Slim's default error handling getting in the way, I wanted to point out that you can actually remove Slim's default ErrorHandler by simply not adding it in the first place or removing the line $app->addErrorMiddleware(...); from your code. This gives you full control to implement your own error-handling strategy without any interference from Slim's built-in mechanisms.

[plasid]

Thanks for the reply Odan,

Any type of error (even fatal) can occur inside a try-catch (try-catch throwable does not know the future), i.e. in a controller or middleware, as you said, Slim will not handle fatal errors and other "traditional" errors, and that is exactly the problem, if it cannot handle ALL errors then rather remove error handling, because.
Now you need to do gymnastics to implement supplementary error handlers, (I will handle these, Slim will handle those....) and configure it accordingly or maybe not... swtich addErrorMiddleware and setDefaultErrorHandler on/off and get different results (I've been using these methods for a long time).
Wouldn't it be nice to have just one, simple, clean, standard, unified way to handle errors in Slim?

[odan]

You've raised some excellent points. It's clear that you've run into the complexities and limitations of Slim's current error-handling system. (I've had the same issues with it)

Note that that Slim's ErrorMiddleware operates within an HTTP-specific context. It's designed to work seamlessly with HTTP request and response objects, making it well-suited for errors that occur during the request-handling process.

However, "traditional" PHP errors, including fatal errors, can occur even before Slim starts running - perhaps during the bootstrap process or other early initialization steps. These errors don't necessarily have an HTTP context, and therefore using a middleware-based approach for handling them doesn't make much sense.

Your suggestion to have a single, unified system to handle all types of errors is very interesting, but due to the "nature" of PHP itself (and not Slim) this is quite "complex". I think it would make more sense to let the developers decide of and how they want to handle a "Throwable" and old-school Errors.

[plasid]

Yep, I'm using a decoupled error handler for all 4 major types, was hoping Slim 5 could address the above - but not a deal breaker, Slim is still amazing.

[akrabat]

Error handling feels like the hardest part of Slim and we've had a few runs at it with different approaches in versions 2, 3 and 4. I'm confident that we can further improve.

I'm happy to look at a proposal for another take with a clear list of benefits, along with ideas on how someone would migrate from 4's error handling to the new one.

My preference would be for an iterative improvement for 5 to minimise the update pain.