This was caused by the set_error_handler() done in DeprecatedCallsLog during startup
Now we are :
* not registering the handler if a PHPUnit test is running (based on a constant set in ItopTestCase::setUp)
* on registration only do it for the required notices
Can happen for example on SVG images
Now the export won't crash anymore, and we'll get a log (export channel, warning level) with the object and attribute causing a problem as context
Co-authored-by: Molkobain <lajarige.guillaume@free.fr>
Doing a code review with Bruno, we agreed to do some little refactoring :
* Level per exception class
- Before the whole ExceptionLog::Log method was a total rewrite of its parent, with some code duplicates... not a good idea : we should better improve LogAPI to make other similar uses possible in the future !
- The logic to get level from config must be in a GetMinLogLevel override
* Write to DB
- Pull up this functionnality in LogAPI
- Add a sCode parameter in GetLevelDefault
Doing this refactoring, I also improved :
* Test the attributes set when creating the EventIssue object : during my dev I had crashes because I didn't filled all the mandatory fields... Having a PHPUnit test checking this will prevent future bugs to happen if attributes are modified in the class or in the object creation method
* Use Throwable instead of Exception : this was added in PHP 7.0 and will allow to catch both Exception and Error
* Because we need to have 2 statements on the same line in \Combodo\iTop\Test\UnitTest\Core\Log\ExceptionLogTest::testLogInFile, I modified the editorConfig file to allow disabling the formatter using comments.
plus:
- the entrypoint is now `LogException()` instead of `FromException()` which sounded more like a factory and less like an active method.
- merge conflicting commit with @molkobain (CC fix)
- remove the writing of the exception object in the error.log context (adding it was an error, it's way too verbose!!).
- Technical note: The context is still used to propagate the exception across several call stack, so it now uses a less generic naming in order to avoid conflicts (see `ExceptionLog::CONTEXT_EXCEPTION`). another solution would have been to add a new parameter to `ExceptionLog::Log()`, but I didn't want to add constraint over the hypothetical evolution of the base class method.
plus:
- the exception object is no more automatically added to the error.log context (it's way too verbose)
- code cleanup (use constant instead of repeated strings)
- ExceptionLog main method is now named `LogException` instead of `FromException`
Try to repair an odd error in the CI:
> Fatal error: Uncaught Exception: Serialization of 'ReflectionClass' is not allowed
avoid instantiation in the provider, delay them to the actual test
Such Exceptions are triggered with a Warning level and default the minimum default level in order to write in DB is above, so the behavior is not modified:
- logs are written in errors.log (with a warning elvel instead of an error)
- logs are not written in DB unless `log_level_min.write_in_db` is changed
They are logged as WARNING level in \DeprecatedCallsLog::ENUM_CHANNEL_PHP_LIBMETHOD channel
Such deprecated notices are generated inside Symfony for example using @trigger_error(..., E_DEPRECATED).
Having such a log will help us migrate to the next lib version !
