fix(ses): fix 2943 error trapping issues
Staged on #2944
Closes: #2941 Refs: #XXXX
Description
In browsers, if errorTrapping: is set to anything other than 'none', then globalWindow.addEventListener('error', event => {...});
is used to log a diagnostic that we wish contain the reason from an unhandled rejection, where the reason should be event.error.
However, in at least some browsers, event.error is absent, null, or undefined. We don't care which. In that case, all we've got is the event, so we log that instead.
Security Considerations
errorTrapping only provides a fixed menu, with the repair doing the privileged registration of a closure. This mechanism does not give post-lockdown user code any non-logging abilities it does not otherwise have. And the logging abilities are consistent with the log being write-only.
With this PR, an event object does get logged, which may contain info we would have liked to redact for normal user code. But this extra info only appears in the log, from which we never redact info anyway.
Scaling Considerations
none
Documentation Considerations
This PR does add an explanation to SES_UNCAUGHT_EXCEPTION.md, which is where it is most likely to be discovered by those who encounter this.
Testing Considerations
The relevant test were already introduced by #2944 , so this PR could illustrate the fix by the diff between it and #2944.
Compatibility Considerations
none. It is hard to imagine anything was depending on the diagnostic being inadvertently empty.
Upgrade Considerations
none
This is now Ready for Review