non-existent E_WARNING reported to NewRelic when exception is caught

[php4fan]

Description

I have this code:

$base_directory = __DIR__ . '/lskdns'; 
ini_set('display_errors', true); 
ini_set('error_reporting', E_ALL); 
try { 
       $n = new RecursiveDirectoryIterator( $base_directory ) ; 
} 
catch (\Exception $e) { 
       echo "<hr>Exception caught: " . $e->getMessage() . "<hr>"; 
}

The code inside the try block causes an exception which gets caught. And yet this gets reported to NewRelic as an E_WARNING:

https://onenr.io/0Zw0mMP6ORv

The exception is getting caught, and there is no E_WARNING at all, so there's nothing here to report to NewRelic.

Note that I have ini_set('display_errors', true), so if there was an E_WARNING it would be printed to the output, which is not the case.

Steps to Reproduce

See code above

Expected Behavior

Nothing should be reported to NewRelic

Observed behavior

A non-existent E_WARNING error is reported to NewRelic.

Relevant Logs / Console output

Your Environment

PHP 7.4 on Debian

Additional context

[zsistla]

Hi @php4fan , thanks for bring this issue to our attention and for providing the reproducible code snippet which really helped when investigating the issue.

#851 is not related to the issue as that is the way the agent has always reported errors with the exception of agent version 10.18.

This was an interesting problem.
In this case, a php E_WARNING error was triggered.  We intercept the error from PHP and record it then pass execution back to PHP.

But this particular case deals with a filehandling which toggles EH_THROW on here: https://github.com/php/php-src/blob/master/ext/fileinfo/fileinfo.c#L176
PHP then handles the error but for a certain number of error codes, PHP triggers an exception if EH_THROW is toggled on: https://github.com/php/php-src/blob/master/main/main.c#L1254C1-L1259C24
and then immediately returns after throwing the exception.

This leads to the case in the issue where the exception that was triggered is caught, but we recorded the error....

It should be addressed in this PR: #876