Fixed PHP 8.2 deprecated dynamic property creation warning

[danielmorell]

This PR fixes the PHP 8.2 deprecated dynamic property creation warning issue #590.

Description of the change

This adds a new class ExceptionWrapper to the SDK. It is used by the ExceptionHandler::handle() and Rollbar::logUncaught() methods. Both functions need to inform the RollbarLogger::report() method that the Exception instance we are passing it is on that was caught by the Rollbar SDK. To do that we had been setting the isUncaught property on the Exception instance. However, the Exception class does not have an isUncaught property. This means we were dynamically creating the property; something PHP allows. However, in PHP 8.2 dynamic property creation has been deprecated.

ExceptionWrapper let's us wrap the exception so that it can be passed to the RollbarLogger::log() method and include an isUncaught property while keeping the log() method compliant with the PSR logging interface.

For test review purposes I pushed the test to the branch first. You can see the failed test in our CI (while the test logs are retained). Also, note, that in the latest commit to this branch the test passes.

This also fixes all the dynamic properties I could find in the test suite.

Type of change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Maintenance
• New release

Related issues

• Fix PHP 8.2 Compatibility #590

Checklists

Development

• Lint rules pass locally
• The code changed/added as part of this pull request has been covered with tests
• All tests related to the changed code pass in development

Code review

• This pull request has a descriptive title and information useful to a reviewer. There may be a screenshot or screencast attached
• "Ready for review" label attached to the PR and reviewers assigned
• Issue from task tracker has a link to this pull request
• Changes have been reviewed by at least one other engineer

[anler]

Question:

Why not add another optional parameter to report that is bool $uncaught = false? I find it better because is only that method the one needing that type of information, besides I find it confusing that we pass a string | Stringeable type to report but it internally coerces it into mixed when passing it to isUncaughtLogData.

If we do this then wrapper types for the exceptions and isUncaughtLogData would no longer be needed. The problem is isUncaughtLogData is public 😅 but I'm failing to see why is it useful hence my desire to remove it altogether.

[danielmorell]

That is a really good question.

I was trying to keep report() as close to log() as possible. I had not considered adding an optional argument, but that would definitely work.

ExceptionHandler currently calls the RollbarLogger::log() method, but that could be updated to use report(), if we went with the optional argument.

Overall, I think that using the optional argument solution would probably reduce complexity. I like it! I'll work on that.