Report errors to the server when the DefaultError is thrown

[jessgusclark]

Rational

Most of the errors this will be used with will be called from code files, however, some do occur within components. Until the code is separated, this module should be able to be called from anywhere.

It allows the developer to send optional parameters developerComment and additionalInfo to provide information that may not be in the error.

• developerComment could be the location of the error, or part of the process, or something where the developer could search for the string in the code and find the location quickly.
• additionalInfo could be the address of the user, or the subdomain they are trying to register, or any other information that would be helpful.

Initial triggers

In this initial batch of errors, they are triggered where the getDefaultError() is found. This is the error that shows the user 'Internal server error'.

It also will send a report in a few places where an error was caught and then console.log out. These errors may be caught at a higher level and not needed, but that is anyone's guess.

wanna test it?

There is a sister branch called error-reporting-manual-trigger that you can clone and run. Navigate to the "Me" section, and under "settings" the first item will be 'Internal Server Error' or the equivalent in your language. Click it! It will send an error to the server.

This sister branch should not be merged due to this commit.

sending an error

The developer can send an error like this:

ReportErrorToServer({
    developerComment: 'User clicked a button',
    errorObject: new Error('this was the error ;-)'),
    additionalInfo: {
      address: '0x123456789',
   },
});

This creates an error report with the following structure:

{
   "comment":"User clicked a button",
   "additionalInfo":"",
   "errorObject":{
      "message":"this was the error ;-)",
      "stack":"Error: this was the error ;-)\n    at Object.reportError [as onPress] (blob:http://localhost:8081/bc7ba6c8-1dd4-4c0f-b8e2-0921cc4d3244:256003:20)\n    at Object.touchableHandlePress (blob:http://localhost:8081/bc7ba6c8-1dd4-4c0f-b8e2-0921cc4d3244:10011:40)\n    at Object._performSideEffectsForTransition (blob:http://localhost:8081/bc7ba6c8-1dd4-4c0f-b8e2-0921cc4d3244:9417:16)\n    at Object._receiveSignal (blob:http://localhost:8081/bc7ba6c8-1dd4-4c0f-b8e2-0921cc4d3244:9343:14)\n    at Object.touchableHandleResponderRelease (blob:http://localhost:8081/bc7ba6c8-1dd4-4c0f-b8e2-0921cc4d3244:9222:12)\n    at Object.invokeGuardedCallbackImpl (blob:http://localhost:8081/bc7ba6c8-1dd4-4c0f-b8e2-0921cc4d3244:22033:16)\n    at invokeGuardedCallback (blob:http://localhost:8081/bc7ba6c8-1dd4-4c0f-b8e2-0921cc4d3244:22124:37)\n    at invokeGuardedCallbackAndCatchFirstError (blob:http://localhost:8081/bc7ba6c8-1dd4-4c0f-b8e2-0921cc4d3244:22128:31)\n    at executeDispatch (blob:http://localhost:8081/bc7ba6c8-1dd4-4c0f-b8e2-0921cc4d3244:22322:9)\n    at executeDispatchesInOrder (blob:http://localhost:8081/bc7ba6c8-1dd4-4c0f-b8e2-0921cc4d3244:22342:11)"
   },
   "userId":"DooqqNxBtN",
   "username":"381730f3-042d-402e-85ea-3e984184ff76",
   "platform":"Android",
   "appVersion":"1.4.2"
}

I am unsure if the stack trace will be helpful. My thinking is that we could put identifying information in the developerComment section that would find the error quickly.

If there is an error.code, as many of the server calls have, that will also be included in the errorObject.

future

In the future, an error could be reported by the user, or a modal could be created with an input box for the user to add additional details. This could be a new parameter in the object that is sent.

[patogallaiovlabs]

LGTM, few minor suggestions only

[itofarina]

I'm just not sure about reporting the errors conditionally inside catch blocks, I might be missing something but I feel like if something was caught, then we should report it.
Apart from that, this PR is great and LGTM :)

[itofarina]

LGTM 👌