Patchers don't report errors to default error handler

[kkmuffme]

It seems php-scoper has some custom error handler configured via symfony, which in my case, doesn't bubble up/report any errors to the default PHP error handler defined.

This is a problem, since any errors from the scoper itself, but also from custom patchers defined in the scoper config file, aren't reported anywhere.

Is there a way to disable the custom error handler/make php-scoper not override any error handlers already defined in the php.ini or auto-prepend files?

[theofidry]

Would you have an example of such a case?

[kkmuffme]

I get neither passed to the error handler defined in our php.ini:

'patchers' => [
        static function (string $filePath, string $prefix, string $contents): string {
            trigger_error( 'hello', E_USER_WARNING );
            throw new \Exception( 'world' );
        },
    ],

When checking the error handler (set_error_handler, restore_error_handler), I see the error handler was changed to some closure, I looked up to be set by symfony.
However, whatever this symfony error handler does, it doesn't bubble/report the error to anywhere in my case.

[theofidry]

Oh indeed. This is because there is a variety of reasons the scoping of a PHP file can fail, for example if it is not a valid PHP. In such a scenario the file is simply copied.

You can find more details when scoping with a higher level of verbosity (with the -v or higher flag).

That said I understand this can be annoying. Maybe another way or do this would be to expose an exception for the patchers which would result in a hard failure rather than being swallowed.

[kkmuffme]

Maybe another way or do this would be to expose an exception for the patchers which would result in a hard failure rather than being swallowed.

That would be best I think, as currently you can end up with broken code (where the file is just copied) and it's unclear why, because no errors are thrown.

You can find more details when scoping with a higher level of verbosity (with the -v or higher flag).

Is there an option to disable the swallowing of errors but not get other unrelated verbose output?

Essentially, for most use cases, it would be better if the default would be to not swallow/modify the PHP error handler at all - as that is what is normally the default behavior. And optionally provide a config/CLI option to disable PHP error reporting

[theofidry]

Is there an option to disable the swallowing of errors but not get other unrelated verbose output?

There is not. I initially wanted to do the reverse: bail out on default and provide an option to skip on error. Unfortunately it has proven to make the tool quite unusable the vest majority of the time.

But that was a long time ago, now there is better way to filter and include files so maybe it's less of a problem. I wouldn't mind experimenting on this, there is a few cases available for review: this project, Box or even this project e2e tests.

[kkmuffme]

As a workaround adding this on top of the scoper config file will fix this and enable the previous/default error handler:

restore_error_handler();
restore_exception_handler();

[theofidry]

I would like to keep it open. The error handler is a nice trick but it won't scale especially when the files are processed in different processes.

[theofidry]

That would be best I think, as currently you can end up with broken code (where the file is just copied) and it's unclear why, because no errors are thrown.

Just in case it's of any help, there is a --stop-on-failure option for the add-prefix command.