This repository has been archived by the owner on Dec 4, 2018. It is now read-only.
Handled/unhandled payload properties #116
Merged
+283
−90
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Handle unhandled Promise rejections in the same way as uncaught exceptions. Sends the error to Bugsnag, logs it and shuts down the process with a non-zero exit code (1).
Also detects if any callback changed "severity" and update "defaultSeverity" accordingly.
kattrali
approved these changes
Sep 25, 2017
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Note this PR is based off of #115 since that is one of the main cases which requires unhandled info.
In order to support the upcoming handled/unhandled product feature this PR ensures that the following properties are set in the
events[]property of the payload:unhandleddefaultSeverityseverityReasonSince these properties are meant to be inferred and set internally by the notifier, but all internal usage went via
Bugsnag.notify(), I extracted the contents of that function into one that is private (ie. within this module's scope only). The private function contains an additional argumenthandledStatewhich cannot be set by the user, and when the publicBugsnag.notify()is called, values are inferred forhandledStatebased on what was supplied.There are a couple grey areas where functionality provided by this module is appeared at first to be "unhandled" and needed a
severityReasonetc.:Bugsnag.intercept(),Bugsnag.autoNotify(). In these instances, the captured errors are reported to viaBugsnag.notify()and therefore gethandledStatevalues applied as if the user had called the public function themselves.(N.B. the
Bugsnag.autoNotify()function is subtly different to theautoNotifyoption. Uncaught exceptions/promises will be reported asunhandled=truewithseverity="error"and the relevantseverityReason.)