SentryService initialization #111
Description
Hey guys
Today I noticed a problem with the SentryService initialization. The exception handlers Networkteam\SentryClient\DebugExceptionHandler and Networkteam\SentryClient\ProductionExceptionHandler are instanciated early in the TYPO3 boot process (see TYPO3\CMS\Core\Core\Bootstrap::initializeErrorHandling()). Because the Networkteam\SentryClient\Service\SentryService::inititalize() method is called in the constructor of the exeption handlers, the configuration options only stem from settings.php or additional.php. Extension's ext_localconf.php file have not been included at this point and thus are ignored. This can lead to unexpected behaviour for example in different environments, or when using Networkteam\SentryClient\SentryLogWriter and logs get written in the bootstrap process.
Although it would be possible to move the call Networkteam\SentryClient\Service\SentryService::inititalize() from the exception handler's constructor to just-before the call to Networkteam\SentryClient\Client::captureException(), it would not completely sove the problem (but nevertheless ease the situation). Exceptions, that are handeled before the TYPO3 boot process is complete, would still not receive configuration options from ext_localconf.php.
To completely solve the problem, the Sentry SDK must be re-initialized after the boot process has completed. For example, it would be possible to listen to TYPO3\CMS\Core\Core\Event\BootCompletedEvent and when it occurs, setting Networkteam\SentryClient\Service\SentryService::$isEnabled to null.
As this is kind of a "race condition problem", it should at least be mentioned in the README file, whichever decision you guys make about it.
What do you think?