Use trigger_error() for errors

[haszi]

Use trigger_error() for triggering the error handler for errors instead of the custom function v(). vsprintf() is used with some errors as this function is used in function v() where formatted strings are being passed to the error handler.

I think this change makes sense semantically and will help with separating the intertwined error handling/info message printing of PhD.

[cmb69]

Hmm, E_USER_ERROR is deprecated as of PHP 8.4.0. Not sure if this is a good temporary solution.

[haszi]

Hmm, E_USER_ERROR is deprecated as of PHP 8.4.0. Not sure if this is a good temporary solution.

I completely forgot about that deprecation.

What do you think would be a good fit here? Using something like E_RECOVERABLE_ERROR?

[cmb69]

I think you can only pass E_USER_* to trigger_error(). I haven't looked at the code, but can we throw some exception and catch that in an exception handler?

[haszi]

I think you can only pass E_USER_* to trigger_error().

You're right, again. And without E_USER_ERROR there is no way to signal to the error handler that we need to bail out after the error message. :-(

I haven't looked at the code, but can we throw some exception and catch that in an exception handler?

I'm trying to avoid switching PhD from errors to exceptions at this stage. I would really prefer merging this, even if it's a just temporary solution, untangling error handling and info message output, and take it from there one step at a time.

Alternatively, I can add a some sort of generic PhD exception, let it bubble up to render.php, catch it there to display the error and then bail out from there. Would that work too for now?

[cmb69]

I'm trying to avoid switching PhD from errors to exceptions at this stage. I would really prefer merging this, even if it's a just temporary solution, untangling error handling and info message output, and take it from there one step at a time.

Taking one step at a time is usually a good idea. :)

Alternatively, I can add a some sort of generic PhD exception, let it bubble up to render.php, catch it there to display the error and then bail out from there. Would that work too for now?

If that doesn't require more complex code changes, I'm fine with it. But don't waste too much time, if it is only an intermediate step.

Maybe @Girgias and/or @jimwins have some suggestions.

[Girgias]

I am fine to use E_USER_ERROR as a temporary measure to help untangle the current mess. :)

[jimwins]

It's just a deprecation (and we're just on 8.2 with the PHP systems), so I'm fine with this as an interim step to cleaning up the code.