Summary of Changes

To do error handling correctly, you really need two levels of exception catching:

• A global handler registered to PHP via set_exception_handler() that can function standalone (without application components in a usable state)
• An application internal handler which can integrate with your application components

Right now we accomplish both with one method, and this can be problematic because it relies on the application framework being in a usable state, an exception caught and processed by the set_exception_handler() callback cannot make this guarantee.

So, this will change our application bootstrap and exception handling so that the set_exception_handler() callback is no longer our existing handler, but the one provided by Symfony's Debug component (as it is shipping in our package) and change CMSApplication::execute() so that it will catch exceptions and render the error page using our existing handler (which is now consistent with the new Console package application). By moving the catching logic into the application class itself, in the future we can make additional API improvements (because we can make arbitrary assumptions on the state of the application) such as being able to dispatch events for plugins to do custom error handling, and we can leave the global PHP handler as a minimalistic processor decoupled from the rest of the framework.

Testing Instructions

At a point in the application process after the error handler is registered and before the application's execute() method is called, throw an Exception; this should be caught by the Symfony handler and the error page their handler builds rendered. Throwing an exception anywhere after execute() is called should hit our handler and be rendered as has always been the case.

Potential Future Enhancements

• Be able to toggle the $debug flag on Symfony's exception handler, which toggles whether a stack trace is displayed; because JConfig is loaded so late in the bootstrap process (which inherently means at the point we're registering the handler JDEBUG is not yet defined) we're unable to programmatically toggle this short of unregistering and reregistering the handler
• Styling the rendered document in a Joomla theme versus the theme Symfony uses (see https://symfony.com/doc/3.4/controller/error_pages.html for an example)