ob handler should not print the output in case of callback exception

[mvorisek]

Description

The following code:

<?php

ob_start(function ($buffer) {
    // return '';
    throw new \Exception('x');
});

echo 5;

try {
    ob_flush();
} catch (\Exception $e) {
    echo $e;
}

Expected output:

-5Exception: x in /in/kQMfY:5
+Exception: x in /in/kQMfY:5
 Stack trace:
 #0 [internal function]: {closure}('5', 5)
 #1 /in/kQMfY(11): ob_flush()
 #2 {main}

https://3v4l.org/kQMfY

PHP Version

any

Operating System

any

[KapitanOczywisty]

Seems like this is same case as #7957 , you're not returning anything thus text is printed normally, not sure if changing that would be desired behavior. You can of course hack this with garbage collector.

[mvorisek]

The output handler can be responsible for data encoding and printing anything on an exception is strictly undesired.

I will target #8867 to master only.

[KapitanOczywisty]

If handler callback is complex and can throw I think try/catch should be inside handler itself. In worst case you can use double ob_start and set some fail state, then first one would suppress output.

Changing throw/exit to not output buffer will probably require RFC or at least dealing with mailing list.

[Danack]

@mvorisek You have an intuition of how a particular piece of code should work, and you think it's a 'bug' that it doesn't work that way. But it's worked that way for close to twenty years.

https://www.hyrumslaw.com/

With a sufficient number of users of an API,
it does not matter what you promise in the contract:
all observable behaviors of your system
will be depended on by somebody.

Have you ever thought about accepting that things that are different from how you expect them to be, might not be bugs that need fixing?