fix: Refactor/9083 logger class

[Cal-L]

Description

This PR refactors the Logger class's error method to take Error object. While we updated the first parameter of the error method to be type Error, the business logic still handles string inputs to prevent breakage (in case there are strings still being passed). Furthermore, this PR converts places where strings were being passed into the error method to pass Error objects instead.

The reason for only allowing for Error objects as the input is because Sentry stack traces relies on the Error object being created at the origin of the error instead of being reconstructed in the Logger class. After these changes, we should see the correct stack trace for errors reported via Logger class.

Related issues

Fixes: #9083

Manual testing steps

• I'd recommend setting up your own Sentry instance for testing
• Once own Sentry instance is setup, update the sentry.properties file with your project values
• Ensure SENTRY_DISABLE_AUTO_UPLOAD is "false"
• Hardcode an error anywhere in the app to call Logger.error and pass in Error object
• In the next line, hardcode an error anywhere in the app to call Logger.error and pass in string object
• Build app in release mode
• Trigger the errors
• Notice the two errors show in Sentry
• The error reported with a string will be missing the trace of the original error
• The error reported with an error will show the correct trace of the original error

Screenshots/Recordings

Before

Stack trace doesn't show origin of error since Logger.error was passed a string

After

Stack trace shows origin of error after Logger.error is passed an Error object

Pre-merge author checklist

• I’ve followed MetaMask Coding Standards.
• I've completed the PR template to the best of my ability
• I’ve included tests if applicable
• I’ve documented my code using JSDoc format if applicable
• I’ve applied the right labels on the PR (see labeling guidelines). Not required for external contributors.

Pre-merge reviewer checklist

• I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed).
• I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots.

[github-actions]

CLA Signature Action: All authors have signed the CLA. You may need to manually re-run the blocking PR check if it doesn't pass in a few minutes.

[github-actions]

Bitrise

❌❌❌ pr_smoke_e2e_pipeline failed on Bitrise! ❌❌❌

Commit hash: d3fa3b2
Build link: https://app.bitrise.io/app/be69d4368ee7e86d/pipelines/26fb6051-f260-4676-b0fe-0b1d3e5375c6

Note

• You can kick off another pr_smoke_e2e_pipeline on Bitrise by removing and re-applying the Run Smoke E2E label on the pull request

[github-actions]

Bitrise

❌❌❌ pr_smoke_e2e_pipeline failed on Bitrise! ❌❌❌

Commit hash: 687807e
Build link: https://app.bitrise.io/app/be69d4368ee7e86d/pipelines/add177a4-a772-4b07-b90a-3082e0b1183c

Note

• You can kick off another pr_smoke_e2e_pipeline on Bitrise by removing and re-applying the Run Smoke E2E label on the pull request

[Cal-L]

E2E failure not related to this PR

[sonarqubecloud]

Quality Gate passed

Issues
3 New issues
0 Accepted issues

Measures
0 Security Hotspots
50.5% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[wachunei]

LGTM!

[NicolasMassart]

Looks good to me.
Please fill the PR description properly for ruture reference and ease of search and tracking:

• issue link
• manual testing (even if just running a unit test and checking it works)
• check boxes in checklist, just to show you considered each item

[Cal-L]

Looks good to me. Please fill the PR description properly for ruture reference and ease of search and tracking:

• issue link
• manual testing (even if just running a unit test and checking it works)
• check boxes in checklist, just to show you considered each item

Thanks for the reminder! Updated ticket description to match just that 👍