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
However, in both the repeatWhen and bindCallback issues, the subscriber's complete method had already been called. That means the call to error was ineffectual and no error was reported because the SafeSubscriber was stopped:
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 via hostReportError.
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:
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: