Unable to handle errors in v1

[plasid]

I cannot see a proper stack trace of errors while I'm developing, which is obviously very frustrating. However, when I switch php error reporting on I can see an exception raised by Diactoros (...Unsupported response reason phrase; must be a string, received NULL...zendframework/zend-diactoros/src/Response.php:185 Stack trace...) , but no trace/indication of where the problem actually occurred, when php error reporting is off then I get a blank screen with server 500 error.

I thought Zend Expressive has default exception and other response handling built in i.e. 404, methodNotAllowed etc, instead of just bombing out on all problems... or is it up to the developer to write this core functionality? I've wasted so much time searching for examples, but as usual nothing that that works... I cannot believe this is so badly documented (or an architecture flaw in v1?)

I mostly use PHP Slim and it has the above baked in, the developer can also override it with custom handlers...simple and to-the-point. I can unfortunately not use Slim and have to solve this error reporting issue with Zend Expressive.. please help

[geerteltink]

I thought Zend Expressive has default exception and other response handling built in i.e. 404, methodNotAllowed etc, instead of just bombing out on all problems... or is it up to the developer to write this core functionality?

Expressive has error handling included, even v1 (which is not supported anymore I think). It has default 404 and error handlers and comes with WhoopsErrorHandler for debugging purposes.

I've wasted so much time searching for examples, but as usual nothing that that works... I cannot believe this is so badly documented (or an architecture flaw in v1?)

I wonder how much time you have spend or where you searched because it is documented here: https://docs.zendframework.com/zend-expressive/v1/features/error-handling/

If you used the skeleton to install expressive it is added by default.

I mostly use PHP Slim and it has the above baked in, the developer can also override it with custom handlers...simple and to-the-point.

Expressive works the same, you can override the default middleware with custom ones.

However, when I switch php error reporting on I can see an exception raised by Diactoros (...Unsupported response reason phrase; must be a string, received NULL...zendframework/zend-diactoros/src/Response.php:185 Stack trace...) , but no trace/indication of where the problem actually occurred, when php error reporting is off then I get a blank screen with server 500 error.

This sounds like a bug we discovered a while ago in Diactoros which was fixed in verions 2.0.3 and 2.1.1. But since you are using expressive v1, I'm not sure if it affects you. The case was that before the middleware pipeline in expressive was started, an exception was thrown. Since the error handling didn't start yet, it couldn't catch the exception obviously, hence the 500 blank pages.

With the little information you gave I can't tell if this affect you, but I hope this helps you somehow figuring out what is wrong.

[plasid]

Thank you for the reply. What I have found to work in v1 is the following:

At the top of my bootstrap (/public/index.php) I have this: error_reporting(E_ALL); ini_set('display_errors', 1);
ini_set("display_startup_errors", 1);

Then in my config/autoload/local.php 'zend-expressive' => [ 'raise_throwables' => true, ]

Without raise_throwables the problem remains, even with PHP error reporting on, so this is vital. I'm working on an old legacy system, but I'm sure if I had to implement try...catch along with the above I could switch off display_errors in production and catch/log these errors.

[weierophinney]

This repository has been closed and moved to mezzio/mezzio; a new issue has been opened at https://github.com/mezzio/mezzio/issues/3.