The track_errors feature was removed in PHP 7.2

track errors was deprecated in 7.2 and removed in 8. so that's not actually true (https://www.php.net/manual/en/errorfunc.configuration.php#ini.track-errors)

There is a recommended alternative - https://www.php.net/manual/en/migration72.deprecated.php#migration72.deprecated.track_errors-and-php_errormsg using error_get_last. Which is also something we use in the framework package - https://github.com/joomla-framework/language/blob/2.0-dev/src/Parser/IniParser.php#L126-L132 - so is there a reason not to implement it?

Yes, you are right, it isn't removed in 7.2. I didn't introduce error_get_last() here, because we aren't handling the $php_errormsg right now anyway. It is simply a bunch of dead code.

Just because we aren't handling errors properly doesn't mean we should just remove the error handling

But there is no error handling and I don't see how we could or would want to include error handling at this point. parse_ini_file() and parse_ini_string() both don't throw any exceptions and only either return an array or false on error. We've so far also swallowed up all errors in this case. We added an @ in front of both parsing calls, which would suppress any errors anyway, then even when it returns a false value, it silently is swallowed up by returning an empty array. All this means that even if we wanted, we couldn't change the behavior of the method at this point. And I honestly don't think we should log an error in a language file to a log file by default.

@Hackwar @wilsonge
Suggestion for 4.4,

• remove the $php_errormsg code
• check error_get_last() if $strings
• if we have an error add a deprecation warning which says that we throw an exception starting with 5.0

While checking the source code I found out that most of the functions calling the parseFile are unable to handle a return value of false some of them directly access it as array and at least one call give the return value directly to a function which has the parameter typed as array which would lead to an exception...

is this ok for you george if you can you rework this pr hannes and rebase it for 4.4 and create a new pr for 5.0 which adds the exception? and of course don't forget the documentation pr.

thanks

I'm happy with that

@Hackwar can you bring this pr uptodate with the requests then I can merge it before beta1

Closing in favor of #41908. Thanks.