You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Oct 23, 2023. It is now read-only.
We have a config option captureUnhandledRejections which is off by default but can be enabled to have Raven capture unhandled rejections automatically.
Here's what we do now:
Capture the rejection
Invoke the install callback which by default will exit the process
In the absence of Raven, unhandled rejections do not currently result in the process exiting, but enabling our captureUnhandledRejections option changes that.
In relation to discussion in #257 we determined that what we should do instead is:
continue doing nothing with unhandledRejections by default
keep the captureUnhandledRejections flag which adds a process.on('unhandledRejection') handler but does not result in calling install()'s onFatalError callback
This is a behavior change, but a good and necessary one. The key that really convinced me of the necessity of this change was that basically there are edge cases where an unhandledRejection event can be emitted but the rejection can later be handled by user application code. We don't want to incorrectly exit prematurely in that case, and this is also in line with our desire to have the exit conditions of a program not change when adding or removing Raven.
Note that unhandled rejections do result in a warning starting with Node 7, and in the future a garbage-collected unhandled rejection will result in the process exiting (see nodejs/node#6375), and this decision should make it easy for us to fall in line with that change when it happens.
The text was updated successfully, but these errors were encountered:
We have a config option
captureUnhandledRejections
which is off by default but can be enabled to have Raven capture unhandled rejections automatically.Here's what we do now:
install
callback which by default will exit the processIn the absence of Raven, unhandled rejections do not currently result in the process exiting, but enabling our
captureUnhandledRejections
option changes that.In relation to discussion in #257 we determined that what we should do instead is:
captureUnhandledRejections
flag which adds aprocess.on('unhandledRejection')
handler but does not result in callinginstall()
'sonFatalError
callbackThis is a behavior change, but a good and necessary one. The key that really convinced me of the necessity of this change was that basically there are edge cases where an
unhandledRejection
event can be emitted but the rejection can later be handled by user application code. We don't want to incorrectly exit prematurely in that case, and this is also in line with our desire to have the exit conditions of a program not change when adding or removing Raven.Note that unhandled rejections do result in a warning starting with Node 7, and in the future a garbage-collected unhandled rejection will result in the process exiting (see nodejs/node#6375), and this decision should make it easy for us to fall in line with that change when it happens.
The text was updated successfully, but these errors were encountered: