I have tested this item ✅ successfully on 625f5ca

Hint for other testers: After having applied the patch you have to run "composer install" to make Joomla work again, otherwise the new symfony error handler component will not be found. Then you can test as descibed.

I have tested this item ✅ successfully on 625f5ca

RTC

Just curious.

What need to make the same "nice message" when error happen in Joomla\CMS\Exception\ExceptionHandler::render()? I not very understood.

Currently it just a white page with "Error: Foobar: Foobar"
eg: add throw new Exception('Foobar'); to templates/cassiopeia/error.php (or make a syntax error there) and open non existing page;

@Fedik it’s the joomla handlers fallback when main context exception handler fails

We can probably switch it to the symfony handler but also we kinda need a method of last resort too

Thanks

We can probably switch it to the symfony handler but also we kinda need a method of last resort too

yeah,
@wilsonge I found with WebAsset this "white error" may happen relatively more often, in case if .json are broken, or dependency incorrect, then it become not possible to render a "usual" joomla error.php.
And I tried to look how to improve that.

What need to make the same "nice message" when error happen in Joomla\CMS\Exception\ExceptionHandler::render()? I not very understood.

Review #20109 which introduced the Symfony code. Basically there are two error handlers in Joomla, the Symfony ErrorHandler component which is the global exception handler and handles bootup errors (basically if something goes wrong in the files that load up Joomla or in loading up the DI container or creating the application classes that will get hit), then there's the Joomla handler which is no longer registered to PHP through set_exception_handler() but manually triggered inside the application's execute() method if a Throwable is uncaught anywhere else. Basically the logic is to use the Joomla code when it can be sanely assumed the application framework booted up correctly (which should also allow application specific features to be used, like now there is an ErrorEvent dispatched from the application before the exception renderer is triggered so a plugin could do something useful with errors now, see how the redirect plugin works in 4.0 compared to 3.x) and fall back to the Symfony handler to as a last resort.