-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Report synchronous errors thrown after subscriber completion #3803
Comments
benlesh
added
type: discussion
AGENDA ITEM
Flagged for discussion at core team meetings
labels
Jun 6, 2018
I'm generally in favor of the solution of sending them to |
cartant
added a commit
to cartant/rxjs
that referenced
this issue
Sep 4, 2018
cartant
added a commit
to cartant/rxjs
that referenced
this issue
Sep 5, 2018
cartant
added a commit
to cartant/rxjs
that referenced
this issue
Sep 7, 2018
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Feature Request
Is your feature request related to a problem? Please describe.
The issue is a re-write (as discussed in the last core team meeting) of issue #3461 - which is not as clearly described as it could have been.
There have been two recent bugs in which errors thrown synchronously - after subscriber completion - were not reported:
repeatWhen
swallowed an error that was thrown due to a re-enterant tocomplete
(described here).bindCallback
swallowed an error thrown synchronously after the callback was invoked.The errors were swallowed because the implementation of
subscribe
attempts to report them in_trySubscribe
by calling the subscriber'serror
method:However, in both the
repeatWhen
andbindCallback
issues, the subscriber'scomplete
method had already been called. That means the call toerror
was ineffectual and no error was reported because theSafeSubscriber
was stopped:Describe the solution you'd like
The errors should not be swallowed; they need to be reported somehow.
Ideally, any errors that cannot be reported via the subscriber's
error
method should be reported viahostReportError
.However, doing so has the potential to break client code, as throwing errors that were previously swallowed would be a breaking change.
Using the mechanism described in #3469, it's possible to navigate the chain of subscribers to determine if any are in fact stopped. If none is stopped, the error can be reported by calling the subscriber's
error
function. If a stopped subscriber is encountered, the error cannot be reported to the subscriber and should instead be reported to the console.Something like this implementation of
reportError
, which could be called in_trySubscribe
:Reporting these errors to the console might not be ideal, but it's far better than swallowing them.
Describe alternatives you've considered
See above, re: reporting via
hostReportError
.Additional context
repeatWhen
issue.bindCallback
issue.The text was updated successfully, but these errors were encountered: