Exception handler

The core component of this extension is to modify the default debug exception handler from TYPO3 core. For this, the EliasHaeussler\Typo3Solver\Error\AiSolverExceptionHandler class is shipped with the extension.

Configuration

In order to active the modified exception handler, it must be explicitly configured at $GLOBALS['TYPO3_CONF_VARS']['SYS']['debugExceptionHandler']. This can be done in the system configuration file config/system/settings.php (formerly public/typo3conf/LocalConfiguration.php):

config/system/settings.php

return [
    'SYS' => [
        'debugExceptionHandler' => 'EliasHaeussler\\Typo3Solver\\Error\\AiSolverExceptionHandler',
    ],
];

Once configured, the exception handler tries to provide a solution for the current exception and shows it on the exception page. Depending on the handled exception, there are various types of problem solving.

Attention

For the exception handler to work as expected, make sure you have added an OpenAI API key. This is an essential step, otherwise the exception handler won't be able to provide AI generated solutions and just shows a warning about the missing API key.

Types of problem solving

Streamed solution

New in version 0.2.0: Feature: #64 - Switch to chat completions and implement solution streams

This variant is automatically used if an exception is triggered in a stage where TYPO3 bootstrapping is already done and therefore a service container exists. In this case, the solution is provided asynchronous from an event stream by a custom middleware /tx_solver/solution.

Solution stream on error page

Note

The extension provides two early-staged middlewares:

1. Ensure solution stream is possible by requesting /tx_solver/ping

2. Provide streamed solution by requesting /tx_solver/solution

Both middlewares are registered to be handled very early, ideally prior to all other middlewares. If you register additional middlewares on your own, make sure they don't conflict with the middlewares provided by this extension.

Read more at Middlewares.

Default solution

There are cases where solution streaming is not possible. For example, if the exception to handle was triggered very early in the bootstrapping process. Those cases prevent solution streaming as it requires a functioning bootstrapping and a successfully built service container.

If solution streaming is not possible, the solution is provided synchronous. This way is less convenient because – depending on the configured attributes – requests to OpenAI may take relatively long, up to several minutes. During the request, no actions can be done as it would interrupt the request and therefore abort problem solving.

Default solution on error page

Note

You can influence long durations a little bit by modifying the attributes used for each request to OpenAI. All supported attributes can be changed in the extension configuration.