Respect PHP ini settings for error reporting

[sebastianfeldmann]

phive registers its own error handler

phive/src/shared/cli/Runner.php

Line 183 in 9dee308

set_error_handler([$this, 'errorHandler']);

that does not respect the PHP ini error_reporting setting.

This is a bit problematic while running builds for new PHP versions.
While phive would most likely run under php 8.4 without any problems but because there are deprecation errors it just crashes.

I think, during execution time deprecations can safely be ignored.

[theseer]

I do see your point. I'll consider it.

I'd also like to have an issue opened for the deprecation though ;)

[sebastianfeldmann]

Sure thing :)

issue #438

[sebastianfeldmann]

Could be fixed like this.
I can open a PR if you want.

phive/src/shared/cli/Runner.php

Line 73 in 9dee308

private $migrationService;

    /** @var MigrationService */
    private $migrationService;

    private $errorLevel;

phive/src/shared/cli/Runner.php

Line 181 in 9dee308

error_reporting(-1);

    private function setupRuntime(): void {
        $this->errorLevel = error_reporting(-1);

phive/src/shared/cli/Runner.php

Line 124 in 9dee308

public function errorHandler(int $code, string $message, string $file, int $line): bool {

    public function errorHandler(int $code, string $message, string $file, int $line): bool {
        if (!($this->errorLevel & $code)) {
            return false;
        }

[theseer]

I'm not sure I understand the proposed change. It uses a hardcoded -1 - so it's identical to what I have - isn't it? Maybe it's too late and I'm jumping between too many projects..

[sebastianfeldmann]

Flow:

• // original behavior (keep)
  trigger all errors error_reporting(-1)
• // proposed change
  use private to store original php ini setting $this->errorLevel = trigger_error(-1)
• // propose change
  while handling errors use the original php ini setting to make the decision if an exception should be thrown if (!($this->errorLevel & $code)) {

this way you could still do something with deprecations in the future (print as warnings after execution...)
but it would not break the phive execution anymore

[theseer]

That probably makes sense.

We should implement that.