[2.1 & 3.0] Using E_USER_ERROR in trigger_error() deprecated in PHP 8.4

[sbulen]

Basic Information

E_USER_ERROR is passed to trigger_error(), indirectly, in the DB routines when preparing a backtrace. There may be other instances.

Source: https://www.php.net/manual/en/migration84.deprecated.php

See:

SMF/Sources/Subs-Db-mysql.php

Line 311 in d49255b

smf_db_error_backtrace('Wrong value type sent to the database. IPv4 or IPv6 expected.(' . $matches[2] . ')', '', E_USER_ERROR, __FILE__, __LINE__);

SMF/Sources/Subs-Db-mysql.php

Line 913 in d49255b

trigger_error($error_message . ($line !== null ? '<em>(' . basename($file) . '-' . $line . ')</em>' : ''), $error_type);

I have learned a few lessons testing #9126 that I will log separately. Pretty sure these affect both 2.1 & 3.0.

Steps to reproduce

Expected result

No response

Actual result

No response

Version/Git revision

2.1 & 3.0 Alpha 4

Database Engine

All

Database Version

No response

PHP Version

8.4

Logs

Additional Information

No response

[jdarwood007]

Only difficult part is, throwing for 2.1 may require a lot of rework. Whereas in 3.0 we can handle this (if we didn't already)

[Sesquipedalian]

(if we didn't already)

We did

[sbulen]

I was thinking we could just return 406 or 500 instead in 2.1...

[jdarwood007]

Great, so 3.0 doesn't need fixed.

That leads me to believe that we are in a difficult spot here. The error is most likely being thrown so it can be caught by another error handler, prior to it being caught by the normal error handler. I think such cases are out of the box where the upgrader.
We may be able to change to E_USER_WARNING, but it's possible that anything checking for it to be strictly E_USER_ERROR would fail.